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1.  INTRODUCTION 


Computer  networks  are  becoming  increasingly  widespread;  their  use  already  permeates  our  everyday  life. 
As  a  consequence,  their  correct  functioning  becomes  paramount.  Given  that  computer  networks  are 
extremely  complex  systems,  the  task  of  certifying  that  they  behave  properly  is  nontrivial. 

This  report  presents  an  exercise  in  verifying  that  a  particular  algorithm  to  realize  an  important  function  in 
computer  networks,  namely  connection  establishment ,  does  indeed  behave  properly.  The  methods  discussed 
are  applicable  for  analyzing  a  wide  range  of  other  network  functions  as  well. 

The  remainder  of  this  section  gives  background  material.  Section  1.1  discusses  the  nature  and  need  for 
connection  establishment  in  computer  networks;  Section  1.2  then  presents  a  new  language  suitable  for  the 
specification  of  protocols;  and  Section  1.3  describes  a  system  in  which  properties  of  such  specifications  can  be 
proved. 

Section  2  presents  a  specification  of  a  connection  protocol  currently  in  use,  given  in  the  language 
introduced  earlier.  Section  3  then  discusses  particular  properties  of  this  protocol  and  shows  their  verification. 

1.1  Connection-Establishment  Protocols 

This  section  presents  the  motivation  for  connection-establishment  protocols  in  general  and  for  the  three- 
way  handshake  used  in  the  ARPANET  in  particular.1  Consider  a  distributed  system  with  several 
interconnected  nodes.  The  nodes  are  connected  by  an  unreliable  transmission  medium  in  which  messages 
may  be  lost  or  duplicated,  and  each  node  has  several  processes.  Imagine  now  that  two  processes  wish  to 
communicate;  a  common  method  to  overcome  the  possible  loss  of  data  is  to  attach  a  sequence  number  to  each 
data  packet  that  flows,  in  either  direction,  between  them.  If  the  two  nodes  can  agree  on  a  starting  number  to 
be  used,  again  in  each  direction,  then  they  will  be  able  to  detect  packets  arriving  out  of  order  or  being 
duplicated. 

Suppose  now  that  the  system,  when  it  is  created,  initializes  the  nodes  to  have  agreed-upon  sequence 
numbers,  thus  allowing  the  data  transfer  to  take  place  immediately.  Unfortunately,  such  systems  are 
impractical,  fora  number  of  reasons. 

First,  since  the  system  is  intended  to  be  distributed,  a  failure  at  one  node  would  require  the  whole  system  to 
be  re-initialized.  Second,  although  there  is  a  potential  for  communication  between  any  two  processes  in  the 
system,  only  a  few  pairs  will  actually  be  engaged  in  data  exchange  at  any  one  time.  Since  the  resources 
needed  to  maintain  communication  between  processes  are  quite  significant,  the  nodes  should  be  able  to  keep 
these  resources  allocated  only  while  the  exchange  is  taking  place,  thus  increasing  their  utilization. 


lTht  reader  familiar  with  the  three-way  handshake  may  skip  this  section. 
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These  considerations  lead  to  the  notion  of  connections :  When  two  processes  wish  to  communicate,  the 
corresponding  nodes  will  cooperate  among  themselves  to  establish  a  common  frame  of  reference,  e.g., 
sequence  numbers  for  data  flowing  in  each  direction,  for  the  exchange  of  data:  when  the  exchange  is 
complete,  the  connection  is  closed,  freeing  the  resources  for  use  by  other  processes.  The  period  of  time  that  a 
particular  connection  is  open  between  two  processes,  i.e.,  the  period  of  time  a  particular  frame  of  reference  is 
in  efFect  is  called  an  incarnation  of  that  connection. 

It  is  clear  that  for  the  exchange  of  data  to  be  successful,  the  two  nodes  must  agree  on  the  state  of  the 
connection.  A  further  problem  is  introduced  by  the  fact  that  the  transmission  medium  may  delay  or  duplicate 
packets  that  flow  betw  een  the  two  nodes.  Since  connections  can  open  and  close,  it  is  possible  for  packets  from 
old  incarnations  to  be  in  the  medium;  when  they  are  present,  they  should  not  be  mistaken  for  packets 
belonging  to  a  newly  opened  connection. 

Since  packets  may  be  lost,  a  positive-acknowledgment  retransmission-on-timeout  scheme  is  used.  In  other 
words,  the  sender  keeps  a  copy  of  each  packet  sent  until  the  receiver  acknowledges  that  the  packet  has  been 
received.  If  no  acknowledgment  arrives  after  some  predefined  amount  of  time,  it  is  assumed  that  the  packet 
or  its  acknowledgment  was  lost  and  it  is  retransmitted.  Acknowledgments  themselves  are  not  acknowledged. 

It  is  important  to  note  that  if  there  is  a  positive  probability  (no  matter  how  small)  that  a  packet  is  lost  then 
it  is  actually  impossible  to  completely  separate  the  connection-establishment  from  the  data  transfer  itself.  To 
see  why.  consider  the  last  (synchronization)  packet  exchanged  during  the  connection  establishment;  each 
node  will  consider  the  connection  to  be  open  upon  sending  and  receiving  this  packet.  It  is  clear  that  the  node 
receiving  this  packet  can  be  sure  that  the  other  node  has  a  compatible  view  of  the  connection.  The  sender, 
however,  cannot  be  so  sure,  given  the  possibility  that  this  last  packet  may  be  lost;  only  when  the  first  data 
packet  arrives  (in  the  reverse  direction)  will  it  be  sure  that  the  other  node  actually  received  it.  Therefore,  the 
sender  node  must  maintain  both  the  data  exchange  and  the  connection-establishment  information  for  that 
period  of  time.  An  equivalent  problem  is  discussed  in  [2], 

In  many  systems,  connections  are  opened  and  closed  quite  frequently.  Since  the  medium  may  duplicate 
packets,  it  is  possible  for  a  connection-request  packet  from  a  previous  incarnation  to  appear  at  one  node  at 
such  a  time  as  to  be  mistaken  for  a  current  one,  thereby  initiating  a  connection  with  the  wrong  frame  of 
reference  (see  [15]). 

A  problem  still  remains  as  to  how  to  identify  packets  from  previous  incarnations  as  being  old.  The 
sequence  numbers  chosen  to  establish  the  frame  of  reference  of  a  new  connection  must  prevent  that. 
Sunshine,  in  [15],  discusses  this  issue  in  more  detail. 

A  protocol  has  been  proposed  to  handle  the  connection-establishment  problems  discussed  so  far.  It  is  called 
the  three-way  handshake  [19, 15].  The  particular  version  used  here  is  taken  from  TCP  [12],  the  second- 
generation  transport-level  protocol  being  used  in  the  ARPA  internet  system. 
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This  protocol  derives  its  name  from  the  sequence  of  steps  a  node  goes  through  in  order  to  establish  a 
connection.  Suppose  that  node  A  wishes  to  communicate  with  node  B  and  that  node  A  takes  the  initiative. 
The  two  nodes  then  go  through  the  following  steps: 

1.  Node  A  sends  node  B  a  connection  request  called  SYN  (for  SYNchronize). 

2.  Node  B  receives  the  SYN  packet,  and  responds  with  a  SYN  of  its  own  iogether  with  an 
acknowledgment  together  called  SYNACK  (for  SYNchronize  and  ACKnowledge). 

3.  Node  A  receives  the  SYNACK  packet  verifies  that  the  ACK  portion  does  indeed  acknowledge  its 
own  previous  SYN,  and  sends  an  ACK  packet  acknowledging  node  B’s  SYN.  At  this  point  node 
A  considers  the  connection  to  be  opened. 

4.  Node  B  receives  the  ACK  packet  verifies  that  it  does  acknowledge  its  own  previous  SYN,  and 
then  considers  the  connection  to  be  opened. 

There  are  two  basic  modes  for  opening  a  connection:  an  active  mode,  in  which  the  issuing  node  takes  the 
initiative;  and  a  passive  mode,  in  which  the  issuing  node  merely  listens  for  incoming  connection  requests,  and 
accepts  the  first  to  come  in.  The  basic  protocol  described  above  can  be  modified  to  handle  the  case  when  both 
nodes  do  an  active  open  simultaneously. 

If  at  any  point  an  incorrect  packet  arrives,  then  a  RST  (reset)  packet  is  sent  back  to  abort  the  connection¬ 
opening  procedure. 

Figure  1-1  contains  a  state-transition  diagram  taken  from  [12].  It  does  not  show  transitions  caused  by  RST 
or  incorrect  packets. 

1 .2  Overview  of  SPEX 

We  present  here  an  overview  of  a  language,  called  SPEX,  to  be  used  for  the  specification  of  a  distributed 
system  in  genera]  and  computer  networks  in  particular.  This  language  will  be  used  later  to  describe  the  three- 
way  handshake  protocol.  As  will  be  evident  from  the  details  given  below,  the  underlying  model  in  SPEX  is 
that  of  a  nondeterministic  state-transition  system,  with  some  specialized  features  to  facilitate  protocol 
specification.  SPEX  is  discussed  at  greater  length  in  [13], 

A  system  is  regarded  as  consisting  of  a  set  of  interconnected  Nodes.  In  the  case  of  the  example  presented 
here,  a  Node  can  be  a  Station  or  a  Medium.  The  pattern  of  interactions  of  the  nodes  constitutes  the  layer's 
definition.  A  particular  pattern  of  behavior  characterizes  a  node’s  type.  A  system  may  in  general  be  composed 
of  several  distinct  types  of  nodes,  each  with  its  own  behavior,  and  may  have  several  instances  of  each  type  of 
node  as  well. 

Thus,  in  order  to  completely  characterize  a  system,  it  is  necessary  to  describe  the  behavior  of  each  type  of 
node  (given  in  the  Node  Behavior  part  of  the  specification),  the  set  of  instances  of  each  node  type  and  the  way 


FORMAL  SPECIFICATION  AND  VERIFICATION  OF 


Figure  1*1:  Three-way  handshake  state-transition  diagram 


the  instances  are  interconnected  (given  in  the  Topology  pan),  and  the  desired  properties  of  the  interactions 
between  the  instances  (given  in  the  Properties  part).  In  addition,  the  specification  of  any  data  types  used  in 
specifying  a  node's  behavior  must  be  included. 

A  node  is  some  entity  that  has  some  internal  State  Variables  and  some  externally  visible  Interface 
Variables ;  these  variables  may  be  of  arbitrarily  complex  data  types  (which  may  be  defined  using  algebraic 
data  type  specification  methods  [9,  7,  8,  5].).  A  node  reacts  to  a  set  of  specified  Events.  When  one  such  event 
occurs,  some  state  variables  and  some  interface  variables  may  have  their  values  changed. 

State  variables  can  be  accessed  only  locally  at  each  node.  Interface  variables,  on  the  other  hand,  can  be 
accessed  from  the  outside-this  is  how  a  node  communicates  with  the  outside  world,  i.e..  other  nodes  in  the 
same  system  or  other  systems  using  the  system  in  which  the  node  is  defined.  Accordingly,  the  interface 
variables  at  each  node  are  divided  into  two  kinds:  those  that  are  exported  to  other  systems,  and  those  that  are 
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connected  to  other  nodes  in  the  same  system.  In  addition,  each  interface  variable  may  have  a  direction  of  data 
flow  associated  with  it,  meaning  that  data  in  that  variable  flows  into  or  out  of  a  node;  if  no  direction  is 
specified,  data  in  that  variable  flows  in  both  directions. 

The  actual  behavior  of  a  node  is  given  by  describing  how  a  node  reacts  to  the  occurrence  of  certain 
specified  events.  Each  event  known  at  a  node  has  a  precondition  associated  with  it;  this  precondition  is  a 
predicate  involving  state  and  interface  variables  at  that  node.  As  long  as  a  precondition  is  true ,  its  associated 
event  is  said  to  be  enabled;  enabled  events  may  fire  at  any  time. 

The  nodes  behavior  is  given  in  terms  of  the  new  values  of  all  its  variables  when  each  of  the  possible  events 
occurs.  All  changes  for  an  event  are  considered  to  happen  simultaneously,  i.e.,  the  events  are  considered 
atomic.  This  means  that  if  any  variable  X  is  used  to  compute  the  new  value  of  some  variable,  the  value  used 
in  the  computation  is  the  value  X  had  before  the  event  happened.  For  brevity’s  sake,  if  a  variable  is  not 
mentioned  on  the  left-hand  side  of  any  event-effects  statement,  then  its  value  is  not  changed  by  the 
occurrence  of  that  event. 

Since  state  variables  are  not  visible  externally,  they  can  be  regarded  as  history  variables  [II]  which 
accumulate  information  about  the  computation. 

Since  interface  variables  are  externally  visible,  it  is  possible  for  an  event  el  at  some  node  Nl  to  change  the 
value  of  some  interface  variable  at  another  node,  say  N2.  In  fact,  el  may  actually  enable  some  event  at  N2 ; 
this  is  effectively  how  nodes  exchange  data  and  synchronize  their  activity. 

The  last  item  necessary  to  completely  describe  a  node's  behavior  is  its  Initial  State,  specifying  the  values  of 
any  variables  at  system-creation  time.  The  most  general  way  to  specify  the  initial  state  is  to  give  predicates 
which  must  be  true  in  the  initial  state;  it  may  not  be  necessary  or  even  possible  to  give  actual  values  to  the 
variables. 

All  of  the  above  must  be  specified  for  each  node  type  that  exists  in  the  system. 

The  overall  system  behavior  specified  is  defined  as  the  set  of  all  valid  sequences  of  events.  A  valid  sequence 
is  formed  by  starting  from  an  initial  state  (i.e.,  a  state  satisfying  the  initial  state  predicates)  and  successively 
firing  enabled  events;  it  may  be  of  infinite  length.  If  it  is  of  finite  length,  then  the  final  state  arrived  at  by 
executing  the  sequence  has  no  enabled  events. 

Once  all  node  types  have  been  specified,  it  is  necessary  to  describe  how  the  several  nodes  are  connected. 
This  is  achieved  by  allowing  interface  variables  at  each  node  to  be  connected  to  interface  variables  at  other 
nodes;  the  intended  semantics  is  that  these  are  in  fact  shared  variables  between  the  corresponding  nodes. 

The  Topology  part  then  specifies  how  the  interface  variables  of  each  ncde  in  the  system  (i.e.,  each  instance 
of  each  type  of  node)  are  connected  to  interface  variables  of  the  other  nodes. 
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The  Properties  section  states  two  kinds  of  properties  of  the  protocol,  Assumed  and  Asserted  properties. 
Asserted  properties  are  those  that  must  be  prov  ed  true  by  the  specifier  and  serve  as  an  additional  check  of  the 
accuracy  of  the  specification.  In  other  words,  proving  these  properties  increases  the  confidence  of  the  specifier 
that  the  specification  corresponds  to  her/his  intuitive  understanding  of  the  system. 

Assumed  properties  are  used  to  define  certain  operations  in  a  noncomputational  fashion  by  giving  input- 
output  relationships  between  arguments  and  returned  values. 

SPEXifications2  can  be  conveniently  translated  into  algebraic  style  data  type  specifications  of  the  kind  that 
are  supported  by  the  Affirm  system  (see  Section  1.3).  This  capability  can  be  exploited  to  prove  properties  of 
the  protocol  using  analysis  methods  from  the  abstract  data  type  specification  domain  or  to  perform  a  limited 
form  of  symbolic  execution  of  the  specification,  w  hich  helps  in  determining  the  accuracy  of  the  specification.3 
This  translation  is  dicussed  in  detail  in  [13]. 

An  overview  of  algebraic  specification  of  data  types  and  of  Affirm  is  given  in  the  next  section. 

1 .3  Overview  of  Algebraic  Specification  of  Data  Types  and  of  Affirm 

The  material  presented  in  this  section  has  been  abridged  from  [4.  17]. 

Affirm  [10]  is  an  experimental  system  for  the  algebraic  specification  of  and  the  verification  of  properties  of 
user-defined  abstract  data  types.  The  heart  of  the  system  is  a  natural  deduction  theorem  prover  for  the 
interactive  proof  of  these  properties,  which  are  stated  in  the  predicate  calculus  extended  with  data  types. 
Programs,  written  in  a  variant  of  Pascal  extended  w  ith  user-defined  abstract  data  types,  may  be  verified  using 
the  inductive  assertion  method  [3].  Additional  features  include  tools  for  the  analysis  of  algebraic 
specifications,  a  library  of  useful  data  types,  and  user  interface  facilities.  Experience  with  Affirm  includes 
extensive  experimentation  with  data  type  specifications,  verification  of  small  programs,  the  specification  and 
partial  proof  of  a  large  file-updating  module,  and  the  proof  of  high-level  properties  of  security  kernels. 

The  specification  and  theorem-proving  portions  of  Affirm  are  relevant  to  the  current  discussion. 

Like  other  specification  and  verification  systems.  Affirm  follows  its  own  particular  theoretical  and 
programming  paradigm--abstract  data  types  specified  algebraically  and  properties  verified  by  rewriting  rule 
techniques.  A  brief  description  of  the  algebraic  style  of  data  type  specifications  and  of  the  theorem-proving 
portions  of  Affirm  follows. 


2' SPEX  ification"  will  be  used  10  mean  SPEX  specification 

3I  e  whether  the  specification  captures  the  designer’s  intuitive  understanding  of  the  system 
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Following  the  algebraic  style  of  data  type  specifications  [9,  7,  8,  6,  5],  a  data  type  is  specified  by  first 
defining  three  sets  of  functions: 

1.  Constructors .  These  functions  create  values  of  the  type.  Their  range  is  the  data  type  being 
specified.  All  values  of  the  type  can  be  described  in  terms  of  some  functional  composition  of 
these  functions. 

2.  Extenders  (or  Modifiers).  ITese  functions  also  have  the  data  type  being  specified  as  their  range, 
but  in  contrast  to  the  constructors,  they  are  not  needed  to  express  values  of  the  data  type- they  are 
derived  operators.  These  functions  can  be  defined  in  terms  of  the  constructors. 

3.  Selectors.  These  functions  yield  values  of  types  other  than  the  one  being  specified.  ITie  general 
term  for  these  functions  is  selector ,  but  functions  yielding  values  of  type  Boolean  are  often  termed 
predicates.  These  functions  are  defined  in  terms  of  the  parameters  of  the  constructors 


For  example,  the  constructors  of  a  queue  are  NewQueue  (the  empty  queue)  and  Add  (appends  an  element 
to  a  queue).  Example  extender  functions  are  Remove  (deletes  the  first  element  from  a  queue)  and  Append 
(concatenates  two  queues).  Observe  that  these  extender  functions  can  be  defined  in  terms  of  the  constructors 
NewQueue  and  Add.  Example  selector  functions  are  Front.  # Elements  and  in  (a  predicate).  These  are 
definable  in  terms  of  the  parameters  to  Add. 

The  effect  of  such  a  specification  is  to  view  values  of  the  type  in  terms  of  the  constructors  which  can  build 
them.  Hence,  all  selectors  and  extenders  are  defined  in  terms  of  these  constructors.  For  example,  the  queue 
of  integers 

<1, 2,3> 

is  represented  (in  infix  form)  as 

((NewOueueOf Integer  Add  1)  Add  2)  Add  3 

The  first  part  of  a  specification  gives  the  signature  of  all  operations,  i.e.,  their  domains  and  their  ranges. 
Figure  T2  shows  an  example  for  the  type  QueueOflnteger. 


declare  q,q’:QueueOf  Integer; 
declare  ^Integer; 

interface  NewOueueOf  Integer,  q  Add  i ;  QueueOflnteger; 
interface  Remove(q),  Append(q,q’)  :  QueueOflnteger; 
interface  #  Elements(q),  Front(q) :  Integer; 
interface  i  in  q  Boolean; 


Figure  1-2:  Signature  of  type  QueueOflnteger 


The  second  pan  of  a  data  type  specification  provides  semantics  for  the  operations  whose  domain  and  range 
information  was  given  in  the  first  pan.  Extenders  and  selectors  are  defined  by  equational  axioms  of  the  form 
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Ihs  =  =  rhs  relating  how  each  function  behaves  when  applied  to  each  of  the  constructors.  Constructor 
functions  are  treated  as  primitive,  unspecified  operations. 

Examples  of  axioms  taken  from  a  specification  of  the  type  QueueOflnieger  are  given  in  Figure  1*3. 


axioms 

Remove(NewQueueOf  Integer)  =  =  NewOueueOt  Integer, 

Remove(q  Add  i)  =  =  if  q  =  NewOueueOt  Integer 
then  q 

else  Remove(q)  Add  i, 

#Elements(NewQueueOf  Integer)  =  *  0, 

#  Elements(q  Add  i)  x  =  #Elements(q)  +  1; 

Append(q,  NewQueueOf Integer)  =  =  q, 

Append(ql,  q2  Add  i)  =  =  Append(ql,  q2)  Add  i, 

Figure  1-3:  Some  axioms  for  type  QueueOflnieger 


Data  types  in  general  have  properties  that  the  specifier  may  wish  to  prove.  For  example,  "the  number  of 
elements  in  the  concatenation  of  two  queues  is  the  sum  of  the  number  of  elements  in  each  queue."  Formally, 
this  property  is  stated  as 

#Elements(Append(q,q’))  =  #Elements(q)  +  #Elements(q’) 


Properties  of  a  data  type  are  proved  using  a  method  called  structural  induction  [14,  7]  which  is  based  on  the 
notion  that  all  values  of  the  data  type  can  be  produced  by  repeated  applications  of  the  constructor  functions. 
To  prove  a  property  Pof  all  element  of  a  data  type,  it  suffices  to  show  that 

1.  It  is  true  for  the  "base"  cases-the  constructors  that  produce  values  of  the  type  without  taking 
values  of  the  type  as  arguments  (e.g.,  P(NewQueue)). 

2.  Assuming  P  is  true  for  some  value  <7,  then  it  is  also  true  for  all  values  obtained  by  applying 
constructors  to  q  (  e.g.,  for  all  q.i  P(q)  implies  P(q  Add  /)). 

There  is  much  more  to  specifying  a  data  type  specification  than  just  giving  a  set  of  axioms.  A  good  data 
type  specification  should  provide  the  desired  set  of  operations.  These  operations  should  have  the  expected 
(intuitive)  properties.  The  axioms  should  also  facilitate  simple  proofs.  In  other  words,  the  type  has  an 
associated  theory •  that  expresses  properties  derived  from  the  axioms.  (Building  these  theories  is  a 
mathematical  art.)  The  main  method  of  proof  of  such  properties  is  induction,  for  which  the  schema  pan  of  a 
type  provides  the  proof  structure. 


Affirm  is  not  exactly  a  proof  checker,  nor  is  it  a  proof  finder.  The  responsibility  for  finding  and  executing 
a  proof  strategy  rests  solelv  with  the  user.  At  each  proof  step,  modifications  are  made  to  a  system-maintained 
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proof  structure.  Then  the  rewriting  rules  of  the  data  types  of  the  program,  together  with  the  rules  of 
propositional  logic,  are  applied  to  simplify  the  proposition  currently  being  worked  upon.  In  general,  the  user 
is  attempting  to  reduce  a  formula  to  a  set  of  subgoals  so  simple  that  their  proofs  are  immediate,  i.e.,  can  be 
obtained  by  the  system  without  further  direction.  Some  example  commands  for  carrying  out  proofs  and  their 
effects  are: 

try*  proposition  Set  up  proposition  as  the  current  goal. 
employ  Induction(v) 

Induction  is  a  user-defined  schema  for  the  type  of  induction  desired  and  v  is  the  variable  to 
be  induced  upon.  The  proof  structure  is  modified  to  show  the  various  cases  of  the 
induction. 

apply  proposition  Use  proposition  as  a  lemma  in  the  proof  (proposition  must  be  proved  or  assumed 
separately).  A  separate  put  command  instantiates  the  variables  in  the  lemma  to  the  proper 
values  in  the  current  goal. 

suppose  proposition 

Break  the  current  goal  into  two  subgoals,  one  with  the  additional  hypothesis  proposition 
and  the  other  with  -  proposition. 

split  Break  up  the  proposition  at  a  designated  spot  into  subgoals,  e.g.,  the  proposition  H  imp  (C/ 

and  C  J  can  be  split  into  the  two  propositions  H  imp  C;  and  (H  and  Cj)  imp  CT 

replace  Replace  subexpressions  with  other  subexpressions  according  to  designated  equalities  in  the 

current  proposition. 

invoke  defn  Invoke  a  definition  defn  that  the  user  has  made  at  some  time. 

The  user  can  explore  various  av  enues  of  proof  until  the  proof  is  complete  or  until  the  conjecture  is  found  to 
be  unprovable,  at  which  point  the  proof  of  the  corrected  conjecture  must  be  restarted  or  the  bad  proof  steps 
corrected. 

Each  theorem  or  intermediate  proposition  in  Affirm  is  represented  by  a  named  node  in  a  directed  acyclic 
graph  called  the  proof forest.  The  proof  of  a  theorem  comprises  a  tree,  whose  named  arcs  represent  Affirm 
commands  and  thus  deductive  steps.  Affirm  checks  for  circularity  within  the  current  tree. 

An  example  of  an  Affirm  proof  is  discussed  in  Section  3. 


1 .4  Relation  to  Other  Work 

There  is  a  large  body  of  work  regarding  techniques  for  specifying  protocols.  These  include  Petri  nets  (and 
related  graph  models),  formal  languages,  sequencing  expressions,  and  (parallel)  programming  languages. 
Much  of  this  work  is  limited  in  expressive  power,  in  the  sense  that  specifications  grow  unproportionally  large 
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as  the  complexity  of  the  protocol  being  specified  increases.  Many  also  suffer  from  lack  of  a  solid  theory  or  of 
automated  tools  for  verification.  Sunshine  [16]  provides  a  survey  of  this  work. 

Although  the  underlying  model  of  SPEX  is  not  new,  it  is  believed  to  be  the  first  language  allowing  the 
formal  specification  of  nondeterministic  state  transition  systems  in  a  modular,  hierarchical  fashion,  and  for 
which  semi-automated  verification  tools  exist.  An  important  advantage  of  the  modularization  and  the 
symbolic  nature  of  the  specification  is  that  there  is  no  combinatorial  explosion  when  analyzing  more  complex 
protocols.  Schwabe  [13]  provides  an  example  in  which  a  complex  protocol,  involving  an  arbitrary  number  of 
nodes,  is  specified  and  verified,  but  where  the  complexity  of  the  proof  is  independent  of  the  number  of  nodes. 
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2.  SPECIFICATION  OF  THE  THREE-WAY 
HANDSHAKE  IN  SPEX 


This  section  examines  a  SPEXification  of  the  three-way  handshake  protocol  described  informally  in 
Section  1.1.  Appendix  1  contains  the  actual  text  of  the  SPEXification. 

First  the  state  variables,  interfaces,  initial  state,  and  events  for  one  station  are  given;  the  main  portion  of  the 
specification  shows  the  behavior  of  the  station  for  each  event.  A  small  specification  for  the  medium  is  also 
given,  stating  that  the  medium  is  essentially  a  queue  with  an  added  LoseMessage  event.  In  the  sequel,  a  brief 
explanation  of  the  SPEX  ification  is  given. 

The  three-way  handshake  protocol  involves  two  nodes  with  identical  behavior.  The  corresponding  node 
type  is  Station. 

Each  station  needs  the  following  state  variables: 

ISS  is  some  constant  to  be  used  as  Initial  Send  Sequence  number. 

Incarnation#  In 

is  an  incarnation  identification  for  the  packets  coming  in  from  the  other  node. 

Incarnation#  Out 

is  an  incarnation  identification  for  the  packets  leaving  this  node. 

OldUnack 

is  the  sequence  number  of  the  oldest  sent  packet  which  has  not  yet  been  acknowledged. 

Seq#ToSend 

is  the  sequence  number  that  should  be  attached  to  the  next  data  packet  to  be  sent 
Seq#ToReceive 

is  the  expected  sequence  number  of  the  next  packet  coming  in. 

Timeout  Buffer 

is  a  queue  of  packets  containing  copies  of  packets  which  have  been  sent  but  not  yet  acknowledged.4 

The  exported  interface  to  using  systems  contains  two  variables: 

Command 

is  a  command  buffer  through  which  the  user  indicates  what  type  of  open  request  is  desired. 


A 

Stnctly  speaking,  TimeoutBuffer  does  not  have  to  be  a  queue,  but  just  a  collection,  of  packets.  Modeling  it  as  a  queue  results  in 
simpler  axioms  in  this  situation. 
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StateQf 

is  a  variable  that  remembers  the  state  of  the  station,  i.e.,  somehow  remembers  the  recent  history  of 
messages  that  have  been  exchanged.  Its  value  can  be  one  of  {Closed,  Listen,  SynSent,  SynReceived, 
Established}. 

Each  station  has  two  interface  variables  which  are  internal  to  the  system,  namely: 

InPort 

is  a  queue  of  incoming  packets,  with  possible  loss. 

Out  Port 

is  a  queue  of  outgoing  packets,  with  possible  loss. 

The  initial  state  of  each  station  requires  that  the  State  of  the  station  be  Closed [  the  TimeoutBufferbe  empty 
and  the  sequence  numbers  and  incarnation  number  of  incoming  packets  be  zero.5 

The  events  to  which  a  station  can  react  are: 

AcdveOpen 

which  is  caused  when  the  user  issues  an  active  open  command.  This  means  that  a  connection  request 
will  be  sent  to  the  other  party. 

PassiveOpen 

which  is  caused  when  the  user  issues  a  passive  open  command.  This  means  that  the  station  will  listen 
for  incoming  connection  requests  and  accept  the  first  one  that  comes. 

Timeout 

which  is  caused  when  a  timeout  occurs,  i.e.,  when  a  certain  amount  of  time  has  elapsed  without  a  packet 
being  acknowledged. 

ReceiveRst 

which  is  caused  when  a  packet  arrives  whose  control  field  is  rst  (reset).  This  is  a  control  packet  used  to 
indicate  the  discovery  of  an  anomalous  situation. 

Receive  Ac  k 

which  is  caused  when  an  acknowledgment  packet  arrives. 

ReceiveSyn 

which  is  caused  when  a  packet  arrives  whose  control  field  is  syn  (synchronize).  This  is  a  connection 
request, 

ReceiveSynAck 

which  is  caused  when  a  packet  which  is  both  an  acknowledgment  and  a  connection  request  arrives. 


5 


Zero  is  used  as  an  arbitrary  initial  value. 
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The  node  type  representing  the  medium  has  only  an  interface  variable.  Buffer,  which  is  a  queue  of  packets. 
There  is  only  one  event  that  can  happen.  Lose  Message,  which  models  the  medium  being  faulty.  Note  that  the 
transmit  operation  of  the  medium  is  modeled  as  an  Add  to  the  queue,  and  the  receive  operation  is  modeled  as 
a  Remove  from  the  queue,  with  the  packet  delivered  obtained  by  Front  of  the  queue  (before  the  Remove). 

The  definition  of  the  data  type  Packet  can  be  found  in  Appendix  II.  A  brief  description  is  given  here. 

The  fields  of  a  packet  are  the  following: 

SeqNumber 

is  the  sequence  number  of  the  packet. 

Seq#  Inc 

is  the  incarnation  number  associated  with  the  sequence  number. 

AckNumber 

is  the  sequence  number  that  the  packet  is  acknowledging. 

Ackflnc 

is  the  incarnation  number  of  the  acknowledgment  field. 

Ctl  is  the  control  field  of  the  packet. 

As  an  illustration  of  the  effects  of  an  event,  consider  the  ActiveOpen  event  (see  page  26).  Its  precondition 
states  that  it  can  fire  only  if  the  StateCf  the  node  is  Closed,  and  the  user  issued  an  active  open  command  by 
placing  the  value  Active  in  the  Command  buffer.  When  this  event  fires,  the  effects  specified  state,  for  instance, 
that  a  SYN  packet  is  sent  to  the  other  side  by  appending  it  to  the  OutPort  interface  variable.  It  is  also 
specified  that  the  StateOf  state  variable  becomes  SynSent. 

Finally,  the  Topology  section  states  that  there  are  two  stations,  Left  and  Right,  connected  by  a  medium  in 
each  direction  (i.e..  Out Pon@ Left,  Buffer@LeftToRight,  and  / nPort@ Right  are  all  a  single  shared  queue). 

The  Properties  section  states  properties  concerning  the  correct  operation  of  the  system  that  will  be 
discussed  in  Section  3. 

The  SPEXification  given  in  Appendix  I  is  a  simplification  of  the  one  given  in  TCP  [12].  The  main 
differences  are: 

►  TCP  allows  connections  between  arbitrary  pairs  of  addresses  within  a  large  address  space.  As  in 
TCP,  the  SPEXification  assumes  this  addressing  function  is  performed  by  a  higher  (sub)  level,  so 
that  only  fixed  pair  of  nodes  need  be  considered. 


►  TCP  uses  a  sequence  number  and  an  initial  send  sequence  number  selection  algorithm  to  handle 
the  problems  of  distinguishing  incarnations.  TCP  sequence  numbers  correspond  roughly  to  a 
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concatenation  of  incarnation  and  sequence  numbers  in  our  specification.  TCP  sequence  numbers 
are  of  finite  size,  whereas  they  are  of  infinite  size  in  the  SPEXification. 

►  The  SPEXification  concerns  itself  only  with  the  connection-opening  phase  of  the  protocol;  it  does 
not  allow  closing  of  the  connection  in  the  middle  of  an  opening.  Likewise,  it  does  not  allow  data  to 
be  sent  while  a  connection  is  being  opened. 

►  When  a  RST  packet  arrives  at  a  node  that  is  in  SYNSENT  state,  the  TCP  remembers  whether  the 
connection  started  via  an  active  or  via  a  passive  open.  If  the  open  was  passive,  the  station  returns 
to  the  LISTEN  state  rather  than  closing  the  connection.  The  SPEXification  always  closes  the 
connection  after  a  reset  This  modification  does  not  affect  the  functional  correctness  of  the 
protocol,  but  makes  the  corresponding  SPEXification  simpler. 


For  the  purposes  of  verifying  properties  of  the  three-way  handshake,  the  SPEXification  has  been  manually 
translated  into  an  algebraic  data  type  specification  that  can  be  understood  by  the  Affirm  system.  Appendix  II 
contains  the  generated  axioms  and  auxiliary  data  type  definitions  (e.g..  Packet,  QueueOfPacket)  in  Affirm 
syntax. 
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3.  VERIFICATION 

3.1  Introduction 

This  section  discusses  the  verification  of  properties  concerning  functional  correctness  and  liveness.  The 
discussion  is  presented  in  terms  of  the  algebraic  style  data  type  specification  as  understood  by  Affirm. 

As  was  discussed  in  Section  1.1,  the  functional  correctness  of  a  connection  protocol  cannot  be  completely 
separated  from  the  succeeding  data  transfer  phase.  This  introduces  a  problem  as  to  the  instant  at  which  the 
claim  of  functional  correctness  should  be  made.  Ideally,  functional  correctness  should  state  that 

At  the  end  of  the  connection  phase,  both  stations  are  in  the  Established  state  and  are 
synchronized,  which  means  that  "old”  data  will  not  be  accepted,  but  "new"  data  will  be. 

Therefore,  it  would  be  necessary  to  describe  at  least  part  of  the  data  transfer  protocol  as  well. 

Because  the  data  transfer  has  been  omitted  from  the  specification,  a  modified  version  of  this  property  must 
be  used.  The  following  sections  describe  this  in  more  detail. 

3.2  Functional  Correctness 

Consider  now  the  Junctional  correctness  of  the  protocol,  as  stated  above,  but  from  only  one  node’s  point  of 
view:6 


(StateOf  =  Established)@Right 
imp  Seq#  ToReceive@Left  =  Seq  #  To$end@ Right  and 
Incarnation#  in@  Left  =  Incarnation  #Out@  Right ; 


In  English,  this  says  that  if  the  station  on  the  Right  side  is  in  the  Established  state,  then  the  connection  is 
synchronized  for  data  flowing  out  of  this  node. 

This  property  is  proved  to  be  invariant  by  inductive  proof  methods  which  are  used  for  abstract  data  types. 
Work  with  this  specification  showed  that  this  theorem  was  not  strong  enough  to  be  used  in  an  inductive  proof, 
for  the  following  reason.  Careful  study  of  the  protocol  shows  that  it  is  possible  for  the  above  properties  to 
hold  in  the  SynSent  state  also,  when  simultaneous  active  open  commands  are  issued  at  both  nodes,  as  follows: 
one  side  may  be  in  the  SynSent  state  and  may  already  have  received  an  acknowledgment  for  its  SYN  packet; 
this  side  would  not  enter  the  Established  state  until  it  receives  the  SYN  packet  from  the  other  side.  This 
situation  is  characterized  by  the  fact  that  OldUnack  (the  oldest  unacknowledged  sequence  number)  is  not  ISS 
anymore.  Since  this  side  has  received  an  acknowledgment  for  its  SYN,  it  can  be  sure  that  the  other  side 
knows  its  Seq#ToSend  and  its  Incarnation# Out. 


S,e  notation  P@n  means  P  is  to  be  evaluated  in  node  n. 
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Hence  the  statement  of  functional  correctness  must  be  strengthened  (for  one  side  only)  as  follows: 
Theorem  FC: 

( (StateOf  =  Established)  or  ((StateOf  =  SynSent)  and  OldUnack-  =  1SS)  )@Right 
imp 

Seq#ToReceive@Left= Seq#ToSend@Right  and 
Incarnation#  In@Left= Incarnation  #Out@Right ; 


This  need  to  strengthen  or  generalize  a  theorem  in  order  to  prove  its  invariance  is  typical  of  inductive  proof 
methods  used  for  abstract  data  types. 

Notice  that  this  strengthened  statement  implies  the  weaker  one,  so  that  proving  the  stronger  one  proves  the 
weaker  one  as  well. 

Figure  3-1  contains  a  proof  tree  for  this  theorem  produced  by  the  Affirm  system;  the  lemmas  and 
definitions  used  are  given  in  Figure  3-2  (these  figures  contain  axioms  and  theorems  stated  using  Affirm 
syntax;  the  correspondence  to  SPEX  syntax  should  be  obvious).7  The  proof  follows  an  inductive  argument 
over  all  possible  events  in  the  system.  Broadly  speaking,  this  can  be  expressed  as  the  following:  given  a  goal 
state  (e.g..  Established),  examine  how  each  event  can  move  the  system  into  that  state  (e.g..  Receive Ack  event  in 
SynReceived  state).  In  general,  there  are  many  states  from  which  the  system  may  move  into  the  goal  state. 
Considering  now  each  of  those  states,  one  uses  the  inductive  hypothesis  to  try  to  prove  the  theorem. 

After  some  examination  of  the  proof  tree,  it  is  possible  to  see  that  most  cases  follow  directly  from  the 
inductive  hypotheses;  this  can  be  seen  in  the  proof  tree  by  looking  at  the  branches  and  noticing  where  only  an 
invoke  IH  command  (possibly  preceded  or  followed  by  some  replace,  cases  and  invoke  commands)  was  given. 
Now  the  cases  are  examined  which  do  not  follow  directly  from  the  inductive  hypotheses,  i.e„  involve  the 
application  of  some  lemmas. 

Consider  what  happens  when  a  ReceiveAck@Right  occurs  (+-«-<  1  ).8  The  relevant  case  to  consider  has  the 
node  at  right  in  SynSent  or  in  SynReceived,  and  the  incoming  acknowledgment  has  the  current  incarnation 
number  (since  otherwise  the  packet  would  be  discarded  as  old).  In  other  words,  the  incarnation  number  in 
the  packet  is  equal  to  Incarnation# Out@Right.  (See  hypotheses  of  theorem  AcksAndSyns  in  Fig.  3-2, 
applied  at  *-«-<2.)  But  if  the  incarnation  number  is  current,  then  there  must  have  been  a  SYN  packet  in  the 
past  which  this  current  packet  acknowledges  (see  definition  of  HasSyn,  invoked  at  «-«-<3).  Thus,  the  current 
ACK  carries  the  same  incarnation  number  that  the  SYN  carried,  which  means  that  the  station  at  left  has  its 
Incarnation# In  set  to  the  incarnation  number  of  that  SYN  packet.  Therefore,  we  can  conclude  that 
Incarnation  #Out@Right=  Incarnation#  In@Left. 

7Numbers  on  the  left  should  be  ignored:  they  result  from  bookkeeping  in  Affirm. 

Q 

Indicators  of  the  form  are  used  to  point  to  the  corresponding  places  in  the  proof  tree 
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theorem  Synchronized.  StateOf(S, Right)  *  Established 

or  StateOf(S, Right)  ■  SynSent  and  01dUnack(S , Right)  ISS(Rlght) 
Imp  synchronlzed(S) ; 

Synchronized  uses  EorSSImpEorSRX,  SynchNoLorCorSSX,  AcksAndSynsX,  FrontInQ%, 
SeqlToSendValsX,  and  Seq#ToRece1veValV 

proof  tree: 

68:!  Synchronized 

apply  EorSSImpEorSR  {proved  by  Scheabe  using  Affirm  120  on  4-Feb-81  In 
transcript  <SCHWA8E>Aff Irmtranscript .3-FEB-81 .2} 

70:  54  put  S*»S 

74:  55  employ  Inductlon(S) 

Empty: 

Immediate 
76:  apr: 

56  employ  Normal Form( 1 1$) 

78:  ActlveOpen: 

57  cases 

80:  65  Invoke  IN 

82:  66  replace 

84:  67  Invoke  synchronized  |  all  | 

84:  (proven!) 

221:  PassIveOpen : {Synchronized .  apr-.} 

58  cases 

223:  125  Invoke  IN 

225:  126  Invoke  synchronized  |  all  | 

225:  (proven!) 

227:  LoseHessage : {Synchronized,  apr:} 

59  invoke  IH 

229:  128  Invoke  synchronized  |  all  | 

233:  (proven!) 

231:  Timeout : {Synchronized ,  apr:} 

60  Invoke  IH 

233:  130  Invoke  synchronized  |  all  | 

233:  (proven!) 

235:  RecelveRst: {Synchronized,  apr:} 

61  cases 

237:  131  employ  Normal Form( 1 ' ) 

239:  Left: 


132  Invoke 

IH 

241: 

134  Invoke 

synchronized 

|  all 

241: 

(proven ! ) 

243: 

Right: 

133  Invoke 

IH 

253: 

136  Invoke 

synchronized 

|  all 

253: -> 

(proven! ) 

88:  RecelveAck: {Synchron Ized,  apr:} 


62  cases 

90:  69  employ  Normal Form( 1 ' ) 

92:  Left: 


70 

Invoke  IH 

94: 

72 

Invoke  synchronized  1  all  1 

94: 

(proven! ) 

96: 

Right: 

<-♦-<1 

71 

Invoke  IH 

98: 

74 

replace 

105 

75 

Invoke  synchronized  |  all  | 

107 

76 

apply  AcksAndSyns 

+-<-<2 

109 

77 

put  pk  *  Front(Med1um( ss ' , 

and  S*ss’ 

Left)) 

111 

78 

apply  FrontlnO 

113 

79 

put  Q  *  Medium^*’,  Left) 

116 

80 

replace 

121 

81 

Invoke  PreCond  |  -4  :  -3  | 

123 

82 

apply  Seq#ToSendVa1s 
put  S*ss' 

125 

83 

127 

84 

Invoke  IncomingAckfVal Id  |  all 

1  *-<-<3 

129 

85 

Invoke  HasSyn 

131 

86 

replace 

133 

87 

apply  Seq#ToReceiveVal 
put  S»ss’ 

135 

88 

135 

(proven! ) 

Figure  3*1:  Proof  tree  for  the  functional  correctness  of  the  three-way  handshake 
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137 

Recei veSyn 

(Synchronized,  apr:} 

63 

cases 

139 

90 

invoke  IH 

141 

91 

replace 

143 

92 

invoke  synchronized  1  all  1 

145 

93 

cases 

150 

94 

replace 

161 

95 

apply  SynchNoLorCorSS 

163 

97 

put  $  =  ss  ’ 

165 

98 

repl ace 

(proven 

) 

167 

Recei veSyn Ac k : {Synchronized ,  apr : } 

64 

cases 

169 

99 

employ  Normal Form{ i ' ) 

171 

Left: 

100 

invoke  IH 

173 

102 

invoke  synchronized  |  all  | 

175 

103 

cases 

177 

104 

replace 

179 

105 

apply  SynchNoLorCorSS 

181 

106 

put  S*ss’ 

181 

(proven ! ) 

183 

Right : {Synchronized ,  apr:.  ReceiveSynAck : 

101 

invoke  IH 

185 

108 

invoke  synchronized  (  all  | 

187 

109 

apply  AcksAndSyns 

189 

110 

put  S=  s  s ' 

and  pk  =  Front(Medium( ss * , 

191 

111 

apply  FrontlnQ 

193 

112 

put  Q  *  Medium(ss’,  Left) 

195 

113 

replace 

199 

114 

invoke  I ncomingAck#Va1 id  |  las 

201 

115 

replace 

203 

116 

invoke  HasSyn 

205 

117 

invoke  PreCond 

207 

118 

replace 

209 

119 

apply  Seq#ToSendVal s 

211 

120 

put  S*ss’ 

213 

121 

replace 

215 

122 

apply  Seq#ToReceiveVal 

217 

123 

put  S*ss* 

219 

124 

replace 

(proven ! ) 

+-<-<7 


)) 

PreCond  |  1  | 


Figure  3-1:  Proof  tree  (continued) 
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theorem  Synchronised,  StateOKS.  Right)  =  Established 
or  StateOf(S,  Right)  =  SynSent 
and  OWUnack(S,  Right)  -  =  ISS(Right) 
imp  synchronized(S); 

theorem  AcksAndSyns,  pk  in  Medium(S,  Left) 
and  StateOf(S,  Left)  -  =  Listen 
and  StateOf(S,  Left)  -  =  Closed 
and  Inc  #  Ack(pk)  =  Incarnation  #Out(S,  Right) 
and  (Control(pk)  s  ack)  or  (Control(pk)  =  synack) 
imp  HasSyn(S.  pk); 

theorem  FrontlnQ,  O-  =  NewQueuOf  Packet  imp  Front(O)  in  Q, 

theorem  Seq  #  ToSendVals,  StateOf(S,  Right)  ~  =  Dosed 
and  StateOf(S,  Right)  -  =  Listen 
imp  Seq  #ToSend(S,  Right)  =  1  +  ISS(Right); 

theorem  Seq  JfrToReceiveVal,  StateOf<S,  Right)  ~  =  Closed 
and  StateOf($,  Right)  -  =  Listen 
and  StateOf(S,  Left)  *  SynReceived 
or  StateOf(S,  Left)  s  Established 
and  Incarnation  #Out($,  Right)  =  Incarnation  #  ln(S,  Left) 
imp  Seq  #ToReceive(S.  Left)  *  1  ♦  ISS(Right), 

theorem  EorSSimpEor SR.  StateOf(S,  Right)  =  Established 

or  StateOf(S,  Right)  =  SynSent 
and  OWUnack(S.  Right)  -  =  ISS(Right) 
imp  StateOf(S,  Left)  =  Established 
or  StateOf(S,  Left)  =  SynReceived; 

theorem  SynchNoLorCorSS,  StateOf(S,  Right)  =  Established 
or  StateOf(S,  Right)  =  SynSent 
and  OWUnack(S,  Right)  -  =  fSS(Right) 
imp  StateOf(S.  Left)  -  =  Listen 
and  StateOf(S,  Left)  -  =  Dosed 
and  StateOf($,  Left)  ~  a  SynSent; 
define  synch  ronized(S) 

=  =  (  Seq  #ToReceive(S,  Left)  a  Seq  #ToSend($,  Right) 
and  Incarnation  #  ln(S,  Left)  a  Incarnation  #Out(S,  Right)), 

HasSyn($,  pk) 

=  =  some  SS,  SS\  pk' 

(  SS  join  SS’  =  S 
and  pk  in  Medium(SS,  Right) 
and  lnc#Seq(pk  )  a  lnc#Ack(pk) 
and  lnc#Seq(pk’)  =  Incarnation  #  I n(S,  Left) 
and  if  Control(pk)  =  synack 
then  Control(pk’)  a  syn 

el9e  (Control(pk’)  a  syn  or  Controi(pk’)  =  synack)); 


Figure  3-2:  Theorems  and  definitions  used  in  the  proof  of  the  three-way  handshake 


20 


FORMAL  SPECIFICATION  AND  VERIFICATION  OF 


For  the  sequence  numbers  to  correspond,  it  suffices  to  see  that,  if  the  state  of  a  node  is  not  Listen  or 
Closed,  then  its  SeqtfToSend  is  always  equal  to  ISS  + 1  (Seq#ToSend  will  not  change  until  data  is  sent  -  see 
theorem  SeqtfToSendVals,  applied  at  and  that  all  SYN  packets  carry  ISS  as  their  sequence  numbers. 

Since  the  SeqtfToReceive  is  taken  from  the  SYN  packet,  it  must  perforce  be  ISS  +  1  (see  theorem 
SeqtfToReceiveVals,  applied  at  Therefore  Seq#ToReceive@Left==Seq#ToSend@Right. 

The  next  relevant  case  is  when  a  ReceiveSyn@Left  occurs  (<-«-<6).  This  can  be  correct  only  if  the  node  at 
left  is  in  either  Listen  or  SynSent:  all  other  cases  either  cause  an  error  or  ignore  the  packet.  But  a  careful 
examination  of  the  state  machine  shows  that  it  is  not  possible  to  have  the  station  at  one  side  in  either  Listen  or 
SynSent,  and  the  other  in  either  Established  or  in  SynReceived  with  OldUnack  ~=  ISS  (theorem 
SynchNoLorCorSS,  applied  at  Therefore  this  situation  really  cannot  occur. 

The  other  relevant  cases  are  when  a  ReceiveSynAck  occurs  at  either  node.  If  it  happens  at  the  node  at  right, 
then  the  proof  follows  the  same  argument  as  the  case  for  the  ReceiveAck@RighL  If  it  happens  at  the  node  at 
left  then  the  proof  follows  the  reasoning  for  the  case  ReceiveSyn@Left. 

3.3  Liveness 

Another  useful  property  that  this  protocol  possesses  is  Liveness ;  which  states  that  either  some  event  in  the 
system  is  enabled  or  the  system  is  in  its  final  state.  Since  open  events  are  user  generated,  these  events  are 
ignored,  and  we  assume  that  the  system  starts  in  a  state  where  neither  side  is  in  the  Closed  state  and  both  sides 
are  not  passively  listening.  In  this  case,  it  is  expected  that  the  correct  protocol  will  complete  the  connection- 
establishment  and  reach  a  final  global  state  in  which  both  sides  have  reached  the  Established  state. 

In  order  to  prove  such  a  property,  however,  it  is  necessary  to  prevent  certain  sequences  from  actually  being 
valid  for  the  system.  These  are  sequences  composed  entirely  of  LoseMessage  or  Timeout  events.  Such 
sequences  reflect  fairness  assumptions  on  the  medium,  as  well  as  finite  capacity.  Thus,  restrictions  must  be 
made  in  the  specification  to  insure  the  fairness  of  the  medium.  These  restrictions  are  incorporated  by 
including  a  limit  on  the  number  of  occurrences  of  the  LoseMessage  event,  as  well  as  on  the  size  of  the 
medium. 

Accordingly,  the  number  of  occurrences  of  the  LoseMessage  event  is  limited  by  having  an  extra  auxiliary 
counter  such  that  LoseMessage  can  be  enabled  only  when  the  counter  is  positive,  and  each  time  LoseMessage 
fires  it  decreases  the  counter  by  one.  It  is  set  to  some  constant  value  each  time  a  message  or  an 
acknowledgment  is  received.  This  constant  value  must  be  finite,  but  can  be  arbitrarily  large. 

The  capacity  of  the  medium  can  be  taken  into  consideration  by  augmenting  the  precondition  of  all  events 
that  put  something  into  the  medium  with  a  test  to  see  if  the  length  of  the  corresponding  queue  is  less  than  a 
certain  constant,  which  again  must  be  finite  but  arbitrarily  large.  This  rules  out  behaviors  in  which  a  node 
times  out  over  and  over,  without  anything  else  happening  in  the  system. 
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With  these  modifications  introduced,  an  attempt  was  made  to  prove  that  this  protocol  is  alive,  i.e.,  it 
satisfies 

Theorem  Liveness: 

For  all  S,i 


[~PreCond(S,ReceiveAT)  and  ~PreCond(S,Timeout) 
and  ~PreCond($,LoseMessage)  and  StateOf-  =  Closed]® i 
and  -(StateOf®  =  Listen  and  StateOf@OppositeSide(i)  =  Listen) 
imp  (StateOf  =  Establis’  ed)@Left  and  (StateOf  =  Established)®  Right ; 

where  AT={Ack,Syn,SynAck,Rst}. 

An  inductive  proof  goes  through  for  all  cases  except  for  ReceiveRst.  After  some  investigation,  it  was  found 
that  there  is  a  scenario  in  which  it  is  possible  for  the  two  nodes  to  end  in  the  Closed  state,  which  is  a 
contradiction  of  the  theorem!  Figure  3-3  shows  this  scenario  (with  SEQ  treated  as  a  single  item  representing 
both  the  sequence  number  and  the  incarnation  number). 

This  situation  is  considered  an  error  because  old  duplicate  packets  in  the  medium  prevent  a  connection 
from  being  established.  Note  that  this  is  a  liveness  error,  not  a  safety  error,  since  nothing  bad  happens,  i.e.,  no 
incorrect  synchronization  or  data  transfer  takes  place,  but  the  intended  progress  does  not  occur. 

Another  situation  in  which  there  is  no  progress  may  occur  because  of  the  introduced  protocol  simplification 
that  a  node  always  returns  to  Closed  state  when  a  RST  packet  arrives.  Note  that  this  is  not  the  scenario 
described  above. 

Interestingly,  if  data  packets  are  allowed  to  be  sent,  this  scenario  can  be  continued  in  such  a  way  that  it 
actually  accepts  data  incorrectly.  It  is  sufficient  for  the  appropriate  old  data  packets  to  arrive  at  Node  A  at  the 
point  Node  A  entered  the  Established  state  and  before  any  RST  packets  were  sent  by  Node  B;  this  is 
indicated  in  Figure  3-3.  However,  it  should  be  noted  that  this  situation  depends  on  an  extremely  unlikely 
timing  of  message  exchanges,  which  is  not  expected  to  be  of  practical  significance. 

This  incorrect  data  can  be  avoided  with  a  small  change  in  the  protocol.  Work  is  under  way  to  verify  that  a 
corrected  version  of  the  three-way  handshake  avoids  it. 

In  [1],  Berthomieu  discusses  the  verification  of  other  types  of  liveness  properties  in  algebraically  described 
state  transition  systems. 
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Node  A 

ms.  b 

CLOSED 

CLOSED 

act.  Open 

<SEQ  =  200XCTL = S YN>  ->  ... 

(delayed) 

<-  <SEQ  =  300XCTL  =  SYN> 

act.  OPEN 

SYNSENT 

SYNSENT 
...rev  SYN 

SYNSENT 

SYN  RECEIVED 

<-  <SEQ  =  301XACK  =  201XCTL  =  ACK> 

snd  ACK 

rev  ACK 

SYNSENT 

<■  <SEQ  =  100XCTL  =  SYN>  old  duplicate  !! 

SYNRECEIVED 

rcvSYN 

ESTABLISHED 

SYNRECEIVED 

snd  ACK 

<SEQ  =  201XACK  =  101XCTL= ACK>  ->  bad  ACK  !! 

***  bad  data  might  be  accepted  here  *** 
e.g.,  <-  <SEQ  =  101XDATA> 

rev  ACK 

ESTABLISHED 

SYNRECEIVED 

<-  <SEQ  =  101XCTL = RST> 

snd  RST 

rev  RST 

CLOSED 

<-  <SEQ  =  300XCTL  =  S YN>  original  delayed  syn 

SYNRECEIVED 

rev  SYN 

CLOSED 

SYNRECEIVED 

snd  RST 

<SEQ = OXACK  =  301XCTL= RST>  -> 

rev  RST 

discard-  bad  ACK # 

rev  ACK 

<-  <SEQ  =  301XACK  =  201XCTL  =  ACK> 

snd  ACK 

CLOSED 

SYNRECEIVED 

snd  RST 

<SEQ  =  201XCTL = RST>  -> 

rev  RST 

CLOSED 

CLOSED 

Figure  3-3:  Example  of  a  liveness  error  in  the  three-way  handshake 
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4.  CONCLUSIONS 


This  report  has  presented  an  exercise  in  the  verification  of  properties  of  a  connection-establishment 
protocol.  A  specification  language  tailored  to  the  need  of  communications  protocols  has  been  proposed,  and 
its  relation  to  a  semi-automated  verification  system  discussed.  This  language  was  then  used  to  specify  a 
connection  protocol  currently  being  used,  and  certain  errors  were  uncovered  using  the  verification  system, 
although  the  major  portion  of  the  protocol’s  operation  was  shown  to  be  correct. 

This  work  is  part  of  an  ongoing  project  to  develop  better  protocol  specification  and  analysis  techniques; 
further  work  is  described  in  [13, 18].  Our  preliminary  experience  indicates  that  the  combination  of  state 
transition  and  abstract  data  type  specification  methods  being  pursued  provides  a  reasonably  convenient  and 
powerful  approach  to  these  problems. 
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I.  SPEXIFICATION  OF  THE  THREE-WAY 
HANDSHAKE 


Node(Station)[ 

State  Variables 

[ 

ISS, 

Incarnation#  In, 

Incarnation#  Out, 

OldUnack, 

Seq#ToSend, 

Seq  #  T  oReceive 
:Nat, 

TimeoutBuffer :  QueueOfPackets, 


Interfaces 

f 

Exported:: 

Command  :  Command, 
StateOf :  SysState, 
Internal:: 

InPort , 

OutPort 

:OueueOfPackets ; 


|  Initial  Sand  Sequence  # 

|  Incarnation  #  of  Incoming  packets 
|  Incarnation  #  of  outgoing  packets 
|  Oldest  unacknowledged  seq .  # 

|  Seq  #  to  put  in  the  next  outgoing  packet 
|  Next  expected  seq  0 
|  Nat  stands  lor  Natural 

j  buffer  with  packets  sent  and  not  acknowledged 


|  One  of  {Active,Passive,Null} 

|  State  of  this  side  of  the  connection 

|  msgs  coming  in 
|  msgs  going  out 


Initial  State 

[ 

Incarnation  #  Out  =  Maxval(lnPort  Append  OutPort)  and|  Maxvai  produces  a  unique  value 

|  see  Properties  section 

Incarnation#  In  =  Oand 
Seq#ToSend  =  Oand 
Seq#ToReceive  =  Oand 
StateOf  =  Closed  and 
OldUnack  =  0, 

TimeoutBuffer  =  NewQueueOfPackets ; 


Events 

[  |  Events  and  their  preconditions 

ActiveOpen  :  PreCond  is  StateOf  =  Closed  and  Command  =  Active, 

PassiveOpen  :  PreCond  is  StateOf  =  Closed  and  Command  *  Passive, 

Timeout :  PreCond  is  TimeoutBuffer  -  *  NewQueueOfPackets, 

ReceiveRst :  PreCond  is  InPort-  =  NewQueueOfPackets  and  Control(Front(lnPort))  =  rst, 
ReceiveAck :  PreCond  is  InPort  -  *  NewQueueOfPackets  and  Control(Front(lnPort))  *  ack, 
ReceiveSyn  :  PreCond  is  InPort-  *  NewQueueOfPackets  and  Control(Front(lnPort)) «  syn, 
ReceiveSynAck :  PreCond  is 

InPort-  =  NewQueueOfPackets  and  Control(Front(lnPort)) «  synack 

) 
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Behavior 

[ 

we  define  some  auxiliary  predicates  and 
[functions  to  improve  readability  ol  the  specilication 

define  IncomingAck  #  Valid  =  = 

( AckNumber(Front(lnPort))  =  +  OldUnack)  and 
Ack  #  lnc(Front(lnPort))  =  Incarnation  #  Out; 

|  Acknowledgment  lor  X  has  Ack  *  X  *  T 


define  IncomingSeq  #  Valid  =  = 

( SeqNumber(Front(lnPort))  =  Seq#ToReceive)  and 
Seq#lnc(Front(lnPort))  =  Incarnation#  In; 


ActiveOperv: 

Command  *■  Null, 

Incarnation#  Out  *■  MaxvalflnPort  Append  OutPort), 

OldUnack  «-  ISS, 

Seq#ToSend«-  +ISS 
StateOf  «■  SynSent 
TimeoutBuffer 

NewOueueOfPackets  Add  pkt(ISS,Maxval(lnPort  Append  Outport), AnyNat.AnyNat.syn) 
OutPort  «■ 

Outport  Add  pkt(ISS,Maxval(lnPort  Append  Outport), AnyNat.AnyNat.syn) ; 


PassiveOpen:: 

Command  *■  Null, 

StateOf  *■  Listen, 

TimeoutBuffer  «■  NewOueueOfPackets; 

ReceiveRst:: 

StateOf  *■ 

if  StateOf  =  SynSent  and  IncomingAck#  Valid 
then  Closed 
else  if  StateOf  =  Listen 
then  Listen 

else  if  IncomingSeq# Valid 
then  Closed 
else  StateOf, 


CONNECTION-ESTABLISHMENT  PROTOCOL 


TimeoutBuffer  «- 

ifStateOf  =  SynSentand  IncomingAck#  Valid 
then  NewQueueOfPackets 
else  if  IncomingSeq  #  Valid 
then  NewQueueOfPackets 
else  TimeoutBuffer, 

InPort  *■  Remove(lnPort), 


ReceiveAck:: 

OldUnack  «■ 

if  StateOf  =  SynSent 
then  if  IncomingAck  #  Valid 
then  +  OldUnack 
else  OldUnack 

else  if  StateOf  =  SynReceived 

then  if  IncomingAck  #  Valid  and  IncomingSeq  tt  Valid 
then  +  OldUnack 
else  OldUnack 
else  OldUnack, 

StateOf  «• 

if  StateOf  =  SynReceived 

then  if  IncomingAck#  Valid  and  IncomingSeq#  Valid 
then  Established 
else  SynReceived 
else  StateOf, 

TimeoutBuffer  «- 

if  StateOf  =  Closed  or  StateOf  =  Listen 
then  NewQueueOfPackets 
else  if  StateOf  =  SynReceived 

then  if  IncomingAck# Valid  and  IncomingSeq# Valid 
then  DeletePacket(TimeoutBuffer,Seq#ToSend) 
else  TimeoutBuffer 
else  if  StateOf  =  SynSent 
then  if  IncomingAck  #  Valid 

then  DeletePacket(TimeoutBuffer,Seq  #  T oSend) 
else  TimeoutBuffer 
else  TimeoutBuffer, 
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OutPort  «- 

if  StateOf  *  Closed  or  StateOf  *  Listen 
or  ((StateOf  =  SynSent)  and  -  Incoming  Ack  #  Valid) 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  if  StateOf  =  Syn Received 

then  if  -IncomingSeq#  Valid 
then  OutPort 

Add  pkt(Seq#ToSend,lncarnation#Out, 
Seq  #  ToReceive, Incarnation  #  In, 
ack) 

else  if  -Incoming Ack# Valid 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 
Ack#  lnc(Front(lnPort)), 
AnyNat.AnyNat, 
rst) 

else  OutPort 
else  OutPort, 


InPort  *■  Remove(lnPort) ; 

ReceiveSyn:: 

Incarnation  #  Out  *■ 
if  StateOf  =  Listen 

then  Maxval(lnPort  Append  OutPort) 
else  Incarnation# Out, 

Incarnation  #  In  «■ 

if  ((StateOf  =  Listen)  or  StateOf  *  SynSent) 
then  Seq#lnc(Front(lnPort)) 
else  Incarnation  #  In, 

OldUnack  *■ 

if  StateOf  =  Listen 
then  ISS 
else  OldUnack, 

Seq  #  ToSend  *■ 
if  StateOf  =  Listen 
then  -t-  ISS 
else  Seq  #  ToSend, 

Seq#  ToReceive  «■ 

if  StateOf  ■  Listen  or  StateOf  *  SynSent 
then  +  SeqNumber(Front(lnPort)) 
else  Seq  #  T oReceive, 
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StateOf  «- 

if  StateOf  =  Listen 
then  SynReceived 
else  if  StateOf  =  SynSent 
then  if  OldUnack  =  ISS 
then  SynReceived 
else  Established 
else  StateOf, 

TimeoutBuffer  *• 
if  StateOf  =  Listen 
then  NewOueueOfPackets 

Add  pkt(lSS,Maxval(lnPort  Append  OutPort), 
+  SeqNumber(Front(lnPort)) 

,Seq  #  lnc(Front(lnPort)), 
synack) 

else  if  StateOf  =  Closed 

then  NewOueueOfPackets 
else  TimeoutBuffer, 


OutPort  «■ 

if  StateOf  =  SynSent 
then  OutPort 

Add  pkt(Seq  it  ToSend, Incarnation  it  Out, 

+  SeqNumber(Front(lnPort)) 

,Seq  it  lnc(Front(lnPort)), 
ack) 

else  if  StateOf  =  SynReceived  or  StateOf  =  Established 
then  if  IncomingSeq  a  Valid 
then  OutPort 
else  OutPort 

Add  pkt(Seq#  ToSend, 

Incarnation#  Out, 

Seq#ToReceive, 

Incarnation#  In, 
ack) 

else  if  StateOf  =  Listen 
then  OutPort 

Add  pkt(ISS,Maxval(lnPort  Append  OutPort), 

+  SeqNumber(Front(lnPort)) 

,Seq  #  lnc(Front(lnPort)), 
synack) 
else  OutPort 

Add  pkt(0’,  Incarnation  #  Out, 

+  SeqNumber(Front(lnPort)) 

,Seq  #  lnc(Front(lnPort)), 
rst), 


InPort  «■  Remove(lnPort) ; 
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ReceiveSynAck:: 

Incarnation  it  In  «- 

It  (StateOf  =  SynSent)  and  IncomingAck  it  Valid 
then  Seq  it  lnc(Front(lnPort)) 
else  Incarnation  it  In, 

OldUnack  «■ 

if  StateOf  =  SynSent 
then  if  IncomingAck# Valid 
then  +  OldUnack 
else  OldUnack 

else  if  StateOf  =  SynReceived  or  StateOf  =  Established 
then  if  IncomingAck#  Valid  and  IncomingSeq#  Valid 
then  +  OldUnack 
else  OldUnack 
else  OldUnack, 

Seq  #  T  oReceive  «- 

if  StateOf  =  SynSent 
then  if  IncomingAck#  Valid 

then  +  SeqNumber(Front(lnPort)) 
else  Seq#ToReceive 
else  Seq# ToReceive, 

StateOf  *■ 

if  StateOf  =  SynSent  and  IncomingAck#  Valid 
then  Established 
else  StateOf, 

TimeoutBuffer  «- 

if  StateOf  =  Closed  or  StateOf  =  Listen 
then  NewOueueOfPackets 
else  if  StateOf  =  SynSent 
then  if  IncomingAck  #  Valid 

then  DeletePacket(TimeoutBuffer,  OldUnack) 
else  NewOueueOfPackets 
else  TimeoutBuffer, 
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OutPort 

if  StateOf  =  Closed  or  StateOf  =  Listen 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  if  StateOf  ■  SynSent 

then  if  IncomingAck#  Valid 
then  OutPort 

Add  pkt(Seq  #  T oSend, Incarnation  # Out, 

+  SeqNumber(Front(lnPort)), 

Seq  #  lnc(Front(lnPort)), 
ack) 

else  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  if  StateOf  =  Established 
then  if  IncomingSeq#  Valid 
then  OutPort 
else  OutPort 

Add  pkt(Seq  #  T oSend, 

Incarnation  #  Out, 

Seq#ToReceive, 

Incarnation#  In, 
ack) 

else  if  StateOf  =  SynReceived 
then  if  -IncomingSeq#  Valid 
then  OutPort 

Add  pkt(Seq  #  ToSend, Incarnation  #  Out, 
Seq  #  T  oReceive, Incarnation  #  In, 
ack) 

else  if  -Incoming Ack#  Valid 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  OutPort, 


InPort  «■  Remove(lnPort); 


Timeout:: 

OutPort  «■  OutPort  Append  TimeoutBuffer ; 

] 

I  Node  Station  |] 
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Node(Medium)[ 

State  Variables[|  No  state  variables  |] 

Interfaces 

[ 

Exported:: 

Buffer :  QueueOfPacket ; 

] 

Initial  State 

[  Buffer  =  NewQueueOfPacket ;  ] 

Events[  LoseMessage :  PreCond  is  Buffer  ~  =  NewOueueOfPacket ;] 
Behavior 
[ 

LoseMessage:: 

Buffer «•  Remove(Buffer) ; 

] 

|  Node  Medium\ ] 

Topology 

[  |  There  is  a  medium  RightToLett  and  a  medium  LeltToRight 

|  There  are  two  instances  ot  node  type  Station:  Lett  and  Right 

Instances:: 

RightToLeft.LeftToRight :  Medium, 

Left, Right :  Station  ; 

Connections:: 

lnPort@  Left, OutPort@  Right  <— >  Buffer@RightToLeft, 
OutPort@Left,lnPort@Right  < — >  Buffer@LeftToRight; 

] 

Properties 

[ 

assume  Maxval(Q), 
forall  pk( 

pk  in  O  imp  (Maxvai(O)  >  Seq  ft  Inc(pk)  and  Maxval(O)  >  Ack  ft  Inc(pk)) 

), 


assert  CorrectSynch, 

((StateOf  =  Established)  or  StateOf  =  SynSent  and  Oldllnack-  =  ISS)@Right  imp 
Seq  #ToSend@ Right  *  Seq  ft  T oRecei ve@ Left  and 
Incarnation#  Out@  Right  =  Incarnation  ft  ln@Left , 

assert  Liveness, 

For  all  i  1 1  can  be  one  ot  (Left.Right) 

(  ~PreCond(ReceiveAck)  and  ~PreCond(ReceiveSyn)  and 
-PreCond(ReceiveSynAck)  and  -PreCond(ReceiveRst)  and 
-PreCond(Timeout)  and  ~PreCond(LoseMessage)  and  StateOf-  *  Closed) @i 
and  -  (StateOf  @i  =  Listen  and  StateOf  @OppositeSide(i)  *  Listen) 
imp  (StateOf  *  Established)®  Left  and  (StateOf  *  Established)®  Right ; 


] 
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II.  AXIOMS  GENERATED  FROM  THE 
SPEXIFICATION  OF  THE  THREE-WAY 
HANDSHAKE 


The  axioms  that  follow  contain  the  translation  of  the  SPEXification  of  the  three-way  handshake  given  in 
Appendix  1.  The  medium  interface  variables  ( InPort \  OutPort  and  Buffer)  have  been  collapsed  into  the 
variable  Medium.  The  precondition  of  event  e  is  called  PreCond(S,e).  The  Command  interface  variable  has 
been  eliminated,  since  it  is  not  really  necessary  when  analyzing  the  properties  of  the  system  specified. 


11.1  Three-Way  Handshake 


type  ThreeWay; 

needs  types  Event.SequenceOfEvent,Packet,OueueOfPackets,SysState,Side; 

declare  Q,q,q*:QueueOf  Packets; 

declare  seq  #  ,seg  #  ,ack  #  ,snd  #  integer; 

declare  cf:ControlField; 

declare  S,SS,SS’ :  Seq  uenceOf  Event; 

declare  pe: Event; 

declare  pk,pk*:Packet; 

declare  i,ii,j:Side; 

interface  I SS(i): Integer; 

interface 

TimeoutBuffer(S,i), 

Medium(S.i) 

:OueueOfPackets; 

interface 

StateOf(S.i) 

:SysState; 

interface 

Maxval(q), 

Incarnation  #  ln(S,i), 

Incarnation  #Out(S,i), 

0*dUnack(S,i), 

Seq#ToSend(S,i), 

Seq  ToReceive(S,i) 

Integer; 

interface  lnduction(S):Boolean; 

{auxiliary  functions  to  help  in  the  readability  of  the  axioms} 

interface  PreCond(S,pe), 

IncomingAck  #  Valid(S.i), 

IncomingSeq  #  Valid(S.i) 

:  Boolean; 

define  {auxiliary  function  definitions} 

PreCond<S,ActiveOpen(i))  *  *  StateOf(S.i)  *  Closed, 
PreCond(S,PasaiveOpen(i))  *  «  StateOf(S,i)«  Closed, 
PreCond(S,Timeout(i))  *  *  TimeoutBuffer(S.i)  -  *  NewOueueOfPackets, 
PreCond(S,LoseMesaage(i))  *  a  Medium(S.i)  -  *  NewOueueOfPackets, 
PreCond(S,ReceiveRst(i))  *  * 

( Medium($,OppositeSide{i))  -  *  NewOueueOfPackets)  and 
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Control(Front(Medium(S,OppositeSide(i))))  =  rst, 
PreCond(S,ReceiveAck(i))  =  = 

( Medium(S,OppositeSide(i))  ~  =  NewOueueOf Packets)  and 
Control{Front(Medium(S,OppositeSide(i))))  =  ack, 

PreCond{S.ReceiveSyn(i))  =  = 

( Medium(S,OppositeSide(i))  -  »  NewOueueOf  Packets)  and 
Control(Front(Medium(S,OppositeSide(i)»)  =  syn, 

PreCond(S.ReceiveSynAck(i))  =  = 

( Medium(S,OppositeSide(i))  -  =  NewOueueOf  Packets)  and 
Control(Front(Medium(S,OppositeSide(i))))  =  synack, 

IncomingAck#  Valid(S.i)  =  = 

( AckNumber(Front(Medium{S.OppositeSide(i))))  =  1  +Oldllnack(S,i))  and 
Inc  8  Ack(Front(Medium(S,OppositeSkJe(i))))  =  Incarnation  #Out(S,i), 

IncomingSeq  #  Valid(S.i)  =  = 

( SeqNumber(Front(Medium(S,OppositeSide(i))))  =  Seq  #ToReceive(S,i)) 
and  lnc#Seq(Front(Medium{S,OppositeSide(i))))  *  Incarnation #ln(S,i); 


axioms  {Initial  State} 

Incarnation  #Out(Empty,i)  =  »  Maxval(Medium(Empty,Left)  Append 
Med  ium(Empty, Right)), 

Incarnation  tfln(Empty.i)  =  =  0, 

OWUnack(Empty.i)  =  =  0, 

Seq#ToSend(Empty,i)  =  =  0, 

Seq#ToReceive(Empfy,i)  »  s  0, 

Medium(Empty.i)  =  =  NewOueueOf  Packets, 

StateOf  (Empty  ,i)  =  =  Closed, 

TimeoutBuffer(Empty,i)  *  =  NewOueueOf  Packets; 


axioms  {Active  Open} 

Incarnation  #  Out(S  apr  ActiveOpen(i)j)  *  = 
if  i  =  j  and  PreCond(S,ActiveOpen(i)) 
then  Max val(Medium(S, Left)  Append  Med ium(S, Right)) 
else  Incarnation  #Out{S,j)t 

Incarnation  #  ln(S  apr  ActiveOpen(i),i)  *  *  Incarnation  #  ln(S,j), 

OfdUnack(S  apr  ActiveOpen<i)tj)  *  * 
if  i  =  j  and  PreCond(S,ActiveOpen(i)) 
then  ISS(i) 
else  OWUnack(S.i), 

Seq  #  To  Send  (S  apr  ActiveOpen(i).j)  =  a 
it  i  =  j  and  PreCond($,ActiveOpen(i)) 
then  1  ♦  ISS(i) 
else  Seq  #  ToSend(S.j), 

SeqJ^ToReceive(S  apr  ActiveOpen(i).i)  *  =  Seq  #ToReceive(S,i), 

StateOffS  apr  ActiveOpen(i),j)  *  * 
if  i  *  j  and  PreCond(S,ActiveOpen(i)) 
then  SynSent 
else  StateOf(S.i), 
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TimeoutButfer(S  apr  ActiveOpen(i).j)  =  = 
ft  i  =  j  and  PreCond(S,ActiveOpen(i)) 
then  NewQueueOf  Packets 

Add  pkt(ISS(i),Maxval(Medium(S,Left)  Append  Med  ium(S, Right)), 
AnyNat.AnyNat.syn) 
else  TimeoutBuffer(S.i), 

Medium(S  apr  ActiveOpen(i)j)  =  - 
rf  i  =  j  and  PreCond(S,ActiveOpen(i)) 
then  Medium(S.i) 

Add  pkt(ISS(i),Maxval(Medium(S,Left)  Append  Medium<S,Right)), 
AnyNai.AnyNat.syn) 
elSe  Medium{S,j); 


axioms  {PassiveOpen} 

I  near  nation#  Out(S  apr  PassiveOpen(i).j)  =  =  incarnation  #Out{S,j), 

Incarnation  #ln(S  apr  PassiveOpen(i)J)  =  =  Incarnation  #  ln(S,j), 

OldUnack($  apr  PassiveOpen(i).j)  =  =  OldUnack(S,j), 

Seq  #ToSend(S  apr  PassiveOpen(i)J)  =  =  Seq  #ToSend(S,j), 

Seq  #ToReceive(S  apr  PassiveOpen(i),j)  =  =  Seq  #ToReceive(S,j), 

StateOf(S  apr  PassiveOpen(i)J)  =  = 
il  i  «  j  and  PreCond(S,PassiveOpen(i)) 
then  Listen 
else  StateOf(S.j). 

TimeoutBuffer(S  apr  PassiveOpen(j).i)  =  =  NewQueueOfPackets, 
Medium(S  apr  PassiveOpen(j),i)  =  =  Medium{S,i); 


axioms  {ReceiveRst} 

Incarnation  #Out(S  apr  ReceiveRst(i).j)  =  =  Incarnation  #  Out(S.j), 

Incarnation  #  ln(S  apr  ReceiveRst(i),j)  *  =  Incarnation  #ln(S,j), 

OldUnack(S  apr  ReceiveRst(i)j)  =  =  OldUnack(S,j), 

Seq  #ToSend(S  apr  ReceiveRst{i),j)  =  *  Seq  #ToSend(S,j), 

Seq  #  ToReceive{S  apr  ReceiveRst(i).j)  =  =  Seq  #ToReceive(S,j). 

StateOf(S  apr  ReceiveRst(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveRst(i))  then 
if  StateOf(S,i)  s  SynSent  and  Incoming Ack  #Valid(S.i) 
then  Closed 

else  if  StateOf(S,i)  =  Listen 
then  Listen 

else  if  IncomingSeq  #  Valid(S.i) 
then  Closed 
else  StateOf(S.i) 
else  StateOf(S.j), 

Timeout Buffer(S  apr  ReceiveRst(i),j)  s  = 
if  i  =  j  and  PreCond(S,ReceiveRst(i)j  then 
if  StateOf(S.i)  =  SynSent  and  lncomingAck#Valid(S,i) 
then  NewQueueOfPackets 
else  if  IncomingSeq  #  Valid(Sj) 
then  NewQueueOfPackets 
else  TimeoutBuffer(S,i) 
else  TimeoutBuffer(S.j), 


Medium(S  apr  ReceiveRst(i)J)  *  = 
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if 


i  =  i 

then  Medium(S.i) 

else  if  PreCond(S,ReceiveRst(i))  and  j  =  OppositeSide(i) 
then  Remove(Medium(S,j)) 
else  Medium<S.j); 


axioms  {ReceiveAck} 

Incarnation  #  Out(S  apr  ReceiveAck(i).j)  =  =  Incarnation  #  Out(S,j), 

Incarnation  #  ln(S  apr  ReceiveAck(i),j)  =  =  Incarnation#  In(S.j), 

OldUnack(S  apr  ReceiveAck(i),j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveAck(i)) 
then  if  StateOf(S.i)  =  SynSent 

then  if  IncomingAck#  Valid(S.i) 
then  1  +OldUnack(S,i) 
else  OldUnack(S.i) 
else  if  StateOf(S.i)  *  SynReceived 

then  if  IncomingAck#  Va!id(S,i)  and  IncomingSeq  #  Valid(S.i) 
then  1  +  OldUnack{S(i) 
else  OldUnack(S,i) 
else  OkJUnack(S.i) 
else  OkJUnack(Sj), 

Seq  #ToSend(S  apr  Receive Ack(i).j)  =  =  Seq  #ToSend(S,j), 

Seq  #ToReceive(S  apr  Receive Ack(i)j)  =  =  Seq  #ToReceive(S,j), 

StateOf(S  apr  ReceiveAck(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveAck(i)) 
then  if  StateOf(S.i)  =  SynReceived 

then  if  IncomingAck#  Valid(S.i)  and  IncomingSeq  #  Valid(S.i) 
then  Established 
else  SynReceived 
else  StateOf(S.i) 
else  StateOf(S,j), 

TimeoutBuffer(S  apr  ReceiveAck(i),j)  *  = 
if  i  =  j  and  PreCond(S,ReceiveAck(i)) 
then  if  StateOf(SJ)  =  Closed  or  StateOf(S.i)  *  Listen 
then  NewQueueOf  Packets 
else  if  StateOf($,i)  =  SynReceived 

then  if  IncomingAck#  Valid(S.i)  and  InccmingSeq  #  Valid(S.i) 
then  DeletePacket(Tin>eoutBuffer(S,i)tSeq  #ToSend(S,i)) 
else  TimeoutBuffer($,i) 
else  if  StateOf(S.i)  =  SynSent 

then  if  AckNumber(Front(Medium(S,OppositeSide(i))))  =  1  +  OkJUnack(S,i) 
then  DeletePacket(TimeoutBuffer(S,i),Seq  #ToSend(S,i)) 
else  TimeoutBuffer(S.i) 
else  TimeoutBuffer(S,i) 
else  Timeout  Buff  er(S,j), 

Medium(S  apr  ReceiveAck(i),j)  *  = 
if  PreCond(S,ReceiveAck(i))  then 
if  i  =  i 

then  if  StateOf(S.i)  s  Closed  or  StateOf(S.i)  =  Listen 

or  {(StateOf{S,i)  =  SynSent)  and  -'lncomingAck#Valid(S,i)) 
then  Medium(S,») 

Add  pkt(AckNumber(Front{Medium(S,Opposite$ide(i)))), 

Inc  #  Ack(Front(Medium(S,OppositeSide(i)))), 

AnyNat.AnyNat, 

rst) 

else  if  StateOf(S.i)  =  SynReceived 

then  if  -IncomingSeq  #  Valid(S.i) 
then  Medium(S.i) 

Add  pkt(Seq  #ToSend(S.i), 

Incarnation  #  Out(S.i), 

Seq  #  ToReceive(S,i), 

Incarnation  #  In(S.i). 
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ack) 


else  H  HncomingAck# Valid(S.i)  then 
Medium(S.i) 

Add  pkt(AckNumber(Front(Medium(S,OppositeSide(i)))), 
Inc  #  Ack(Front(Medium(S,OppositeSide(i)))), 


AnyNat.AnyNat, 

rst) 

else  Medium{S,i) 
else  Medium(S.i) 
else  if  j  =  OppositeSide(i) 

then  Remove(Medium(S,j)) 
else  Medium(SJ) 
else  Medium(SJ); 


% 

* 


axioms  {ReceiveSyn} 

Incarnation  tt Out(S  apr  ReceiveSyn(i)j)  =  = 
if  i  s  i  and  PreCond(S,ReceiveSyn(i))  then 
if  StateOf(S.i)  =  Listen 

then  Maxval(Medium(S,Left)  Append  Medium(S, Right)) 
else  Incarnation  #  Out(S.i) 
else  Incarnation  #Out(S,j), 

Incarnation  tt  in(S  apr  ReceiveSyn(i).j)  ^  = 
if  i  =  j  and  PreCond(S.ReceiveSyn(i))  then 
if  ((StateOf(S,i)  =  Listen)  or  StateOf(S.i)  =  SynSent) 
then  Inc  #Seq(Front(Medium(S,OppositeSide(i)))) 
else  Incarnation  tt  In(S.i) 
else  Incarnation  #ln($,j), 

OldUnack(S  apr  ReceiveSyn(i).j)  =  = 
if  i  s  j  and  PreCond(S,  ReceiveSyn  (i))  then 
if  StateOf(S.i)  =  Listen 
then  lSS(i) 
else  OidUnack(S.i) 
else  OldUnack(SJ), 

Seq#ToSend(S  apr  ReceiveSyn(i).j)  =  = 
if  j  s  j  and  PreCond(S.ReceiveSyn{i))  then 
if  StateOf(S.i)  =  Listen 
then  1  +  ISS(i) 
else  Seq  tt  ToSend{S,i) 
else  Seq  #ToSend(S,j), 

Seq  #ToReceive(S  apr  ReceiveSyn(i).j)  =  = 
if  i  a  j  and  PreCond<S,ReceiveSyn(i)) 
then  if  StateOf(S.i)  =  Listen  or  StateOf(S,i)  =  SynSent 

then  1  +  SeqNumber(Front(Medium{S,OppositeSide(i)))) 
else  Seq  tt  ToReceive(S.i) 
else  Seq  tt  ToReceive(S,j), 

StateOf(S  apr  ReceiveSyn(i)J)  =  = 
if  i  =  l  and  PreCond(S.ReceiveSyn(i)) 
then  if  StateOf(S.i)  =  Listen 
then  SynReceived 
else  if  StateOf(S.i)  *  SynSent 
then  if  CHdUnack(S.i)  =  ISS(i) 
then  SynReceived 
else  Established 
else  StateOffS.i) 
else  StateOf(Sj), 

TimeoutBuffer(S  apr  ReceiveSyn(i),j)  s  * 
if  i  =  j  and  PreCond(S.ReceiveSyn(i)) 
then  if  StateOf(S.i)  =  Listen 

then  NewOueueOf  Packets 

Add  pkt(iSS(i).Maxval(Medium(S,Left)  Append  Medium(S, Right)), 
1  ♦  SeqNumber(Front(Medium(S,OppositeSide(i)))) 

,lnc  tt  Seq(Front(Medium(S.OppositeSide<i)))). 
synack) 
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else  if  StateOf(S.i)  =  Closed 
then  NewQueueOf  Packets 
else  TiroeoutBuffer(S.i) 
else  Timeout Buffer( S,j), 

Medium(S  apr  ReceiveSyn(i).j)  =  = 
a  PreCond(S,ReceiveSyn(i))  then 
rt  i  =  i 

then  if  StateOf{S,i)  =  SynSent 
then  Medium(S.i) 

Add  pkt(Seq  #ToSend(S,i). Incarnation  #  Out(S.i), 

1  +  SeqNumber(Front(Medium(S.OppositeSide(i)))) 

,lnc  #  Seq(Front(Medium(S,OppositeSide(i)))), 
ack) 

else  rt  StateOf(S.i)  =  SynReceived  or  StateOf(S,i)  =  Established 
then  if  IncomingSeq  tt  Valid(S,i) 
then  Medium(S.i) 
else  Medium(S.i) 

Add  pkt(Seq  #ToSend(S,i), Incarnation  #Out(S,i), 

Seq  tt  ToReceive(S.i). Incarnation  tt  ln(S,i), 
ack) 

else  rt  StateOf(S.i)  =  Listen 
then  Medium(S.i) 

Add  pkt(ISS(i),Maxval(Medium(S,Left)  Append 
Med  ium(S,  Right)), 

1  ♦  SeqNumber(Front(Medium(S,OppositeSide(i)))) 
,lnc  tt  Seq(Front(Medium{S,OppositeSide(i)))), 
synack) 

else  Medium(S.i) 

Add  pkt(0,Maxval(Medium(S,left)  Append 
Medium(S.Right))  t 

1  +  SeqNumber(Front(Medium{S,OppositeSide(i)))). 
Inc  tt  Seq(Front(Medium(S,OppositeSide(i)))), 
rst) 

else  h  j  a  OppositeSide(i) 

then  Remove(Medium(S,j)) 
else  Medium(S.j) 
else  Medium(S.i); 

axioms  {ReceiveSynAck} 

Incarnation  #Out(S  apr  ReceiveSynAck(i).j)  =  =  Incarnation  #Out(S,j), 

Incarnation  #ln<S  apr  ReceiveSynAck(i).i)  =  = 
if  i  =  j  and  PreCond(S,ReceiveSynAck(i))  then 
if  (StateOf(S.i)  *  SynSent)  and  Incoming  Ack  tt  Valid(S.i) 
then  Inc  tt  Seq(Front{Mediuro(S,OppositeSide(i)))) 
else  incarnation  tt  ln(S,i) 
else  Incarnation  tt  ln(S,j), 

Seq#ToSend(S  apr  ReceiveSynAck(i).j)  =  *  Seq#ToSend(S,j), 

OWUnack(S  apr  ReceiveSynAck! i),j)  *  * 
if  i  =  j  and  PreCond(S,ReceiveSynAck(i)) 
then  if  StateOf(S.i)  =  SynSent 

then  If  lncomingAck#Valid{S,i) 
then  1  +  OldUnack(S.i) 
else  OUUnack(S.i) 

else  if  StateOf(S.i)  *  SynReceived  or  StateOf(S.i)  *  Established 
then  if  Incoming  Ack#  Valid(S.i)  and  IncomingSeq  #  Valid(Sj) 
then  1  +  OldUnack!S,i) 
else  OWUnack(S,i) 
else  OldUnack(S.i) 
else  OkJUnack(S,i), 

Seq#ToReceive(S  apr  ReceiveSynAck(i).j)  *  « 
if  i  *  j  and  PreCond(S,ReceiveSynAck(i)) 
then  if  StateOf(S,i)  *  SynSent 
then  if  lncomingAck#Valid(S,i) 

then  1  ♦  SeqNumber(Front(Medium(S,OppositeSide(i)))) 
else  Seq  #ToReceive(S,i) 
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else  Seq  8  ToReceive(S.i) 
else  Seq  8  ToReceive(S.j). 

Stated  (S  apr  ReceiveSynAck(i).j)  =  = 
if  i  =  i  and  PreCond(S.ReceiveSynAck(i)) 
then  if  StateOf(S.i)  =  SynSent  and  IncomingAck#  Valid(S.i) 
then  Established 
else  StateOf(S.i) 
else  StateOf(S,i), 

TimeoutBuffer(S  apr  ReceiveSynAck(i).j)  =  = 
if  i  =  i  and  PreCond{S,ReceiveSynAck(i)) 
then  il  StateOf(S.i)  =  Closed  or  StateOf(S.i)  =  Listen 
then  NewQueued  Packets 
else  if  Stated (S.i)  =  SynSent 

then  if  IncomingAck#  Valid(S.i) 

then  DeletePacket(TimeoutBuffer(S,i).OIdUnack(S.i)) 
else  NewQueued Packets 
else  TimeoutBuffer(S,i) 
else  TimeoutBuffer(S.j). 

Medium(S  apr  Receives yn Ac k{i),j)  = 
if  PreCond(S,ReceiveSynAck(i))  then 

if  i  =  j 

then  if  Stated(S.i)  =  Closed  or  Stated(S.i)  =  Listen 
then  Medium(S.i) 

Add  pkt(AckNumber(Front{Medium(S.OppositeSide{i)))), 

Inc  8  Ack(Front(Medium(S.OppositeSide(i)))). 

AnyNat.AnyNat. 

rst) 

else  if  Stated(S.i)  =  SynSent 

then  if  IncomingAck  #  Valid(S.i) 
then  Medium(S.i) 

Add  pkt(Seq  8  ToSend(S.i), Incarnation  8  Out(S.i), 

1  +  SeqNumber(Front(Medium(S.OppostteSide(i)))) 

,lnc  8  Seq(Front(Medium(S.OpposffeSfde(f)))), 
ack) 

else  Medium(Sj) 

Add  pkt(AckNumber(Front(Medium{S,OppositeSide(i)))). 

Inc  8  Ack(Front(Medium(S.OppositeSide(i)))). 

AnyNat.AnyNat, 

rst) 

else  if  Stated(S.i)  -  Established 
then  if  IncomingSeq  8  Valtd(S.i) 
then  MediumfS.i) 
else  Medium(S.i) 

Add  pkt(Seq  8  ToSend(S.i), 

Incarnation  8  Out(S,i), 

Seq  8  ToReceive(S.i), 

Incarnation  8  In(S.i). 
ack) 

else  if  Stated(S.i)  =  SynReceived 
then  if  -IncomingSeq  JfrValtd(S.i) 
then  Medium(S.i) 

Add  pktfSeq  8  ToSend(S.i), 

Incarnation  8  Out(S.i). 

Seq  8  ToReceive(S.i), 

Incarnation  8  In(S.i), 
ack) 

else  if  -IncomingAck#  Valid(S.i)  then 
Medium(S.i) 

Add  pkt(AckNumber(Front(Medium(S,OppositeSide(i)))). 
Inc  8  Ack{Front(Medium{S.OppositeSkje(i)))), 
AnyNat.AnyNat, 
rst) 

else  Medium(S.i) 
else  Medium(S.i) 
else  if  i  *  OppositeSide(i) 
then  Remove(Medium(S,j)) 
else  Medium(S.j) 
else  Medium(S.j); 
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axioms  {Timeout} 

Incarnation  #  Out(S  apr  Timeout(i),j)  *  =  Incarnation  #Out(S,j), 

Incarnation  #  ln(S  apr  Timeout(i).j)  =  *  Incarnation  #ln($,j), 

OkJUnack(S  apr  Timeout(i).j)  =  =  OldUnack(S.j), 

Seq#To$end{S  apr  Timeout(i),j)  s  =  Seq  #ToSend(S,j), 

Seq#ToReceis/e(S  apr  Timeout(i),i)  =  =  Seq  #ToReceive(S,j), 

StateO*{S  apr  Timeout(i),j)  =  =  StateOf(SJ), 

Medium(S  apr  Timeout(i).j)  =  = 
if  i  =  j  and  PreCond(S,Timeout(i)) 
then  Append(Medium(S,i),TimeoutBuffer{S,i)) 
else  Medium(S.j), 

TimeoutBuffer(S  apr  Timeout(i)J)  =  =  TimeoutBuffer(S.j); 
axioms  {LoseMessage} 

Incarnation  # Out (S  apr  LoseMessage(i).j)  =  =  Incarnation  JfrOuUSj), 

Incarnation  #ln(S  apr  LoseMessage(i).j)  =  =  Incarnation  #tn(S,j), 

OldUnack(S  apr  LoseMessage(i)J)  =  =  OldUnack(S,j), 

Seq#ToSend(S  apr  LoseMessage(i).j)  -  -  Seq  #ToSend(S,j), 

Seq#ToReceive{S  apr  LoseMessage{i),j)  s  =  Seq  #ToReceive(S,j), 

StateOf(S  apr  LoseMessage{i),j)  «  =  StateOf(Sj), 

Medium(S  apr  LoseMessage(i)J)  =  = 
if  i  =  j  and  PreCond($,LoseMessage(i)) 
then  Remove(Medium(S,i)) 
else  Medium(S,j), 

TimeoutBuffer(S  apr  LoseMessage(i)J)  =  =  TimeoutBuffer(S,j); 


11.2  Auxiliary  Data  Type  Definitions 

type  Packet; 

needs  types  Integer,  ControlField; 

declare  dummy,  pk:  Packet; 

declare  seq  # ,  ack  U ,  inc  #  s,  inc  #  a:  Integer; 

declare  cf :  ControlField; 

interface  pkt(seq  # .  inc  #  s,  ack  # ,  inc  #  a,  cf):  Packet; 

interfaces  Seq Number(pk),  AckNumber(pk),  lnc#Seq(pk),  lnc#Ack(pk):  Integer; 
interface  Control(pk):  ControlField; 
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axiom 

) 


dummy  =  pk 

=  =  (  (SeqNumber(dummy)  =  SeqNumber(pk))  and  AckNumber(dummy 

=  AckNumber(pk) 
and  Control  (dummy)  =  Control(pk) 
and  Inc#  Ack(dummy)  «  lnc#Ack(pk) 
and  Inc  tt  Seq(dummy)  =  lnc#Seq(pk)); 


axiom  SeqNumber(pkt(seq  tt ,  inc  tt  s,  ack  # ,  inc  #  a,  cf))  =  =  seq  tt ; 
axiom  AckNumber(pkt(seq  tt .  inc  tt  s,  ack  tt ,  inc  tt  a,  cf))  =  =  ack  tt ; 


axiom  Inc  tt  Seq(pkt(seq  tt ,  inc  tt s.  ack  tt ,  inc  tt  a,  cf))  =  =  inc  tt s; 


axiom  Inc  tt  Ack(pkt(seq  tt ,  inc  tt  s.  ack  tt ,  inc  tt  a,  cf ))  =  -  inc  tt  a; 


axiom  Control(pkt(seq  tt .  inc  tt  s,  ack  tt ,  inc  tt  a,  cf ))  =  =  cf ; 

end  (Packet)  ; 
type  OueueOfPacket; 


needs  type  Packet 

declare  dummy,  q,  ql,  q2,  qq  OueueOfPacket; 
declare  i,  it,  i2,  ii:  Packet; 

interfaces 

NewOueueOf Packet,  q  Add  i,  Remove(q). 
Append(qt,  q2).  que(i):  OueueOfPacket; 

infix  Add; 


interlaces 

Front(q),  Back(q):  Packet; 
interfaces 

NormalForm(q),  Induction(q),  i  in  q:  Boolean, 

•nfix  in; 

axioms  dummy  =  dummy  =  =  TRUE, 

q  Add  i  =  NewQueueOf Packet  =  =  FALSE, 

NewOueueOf  Packet  =  q  Add  i  =  =  FALSE, 
ql  Add  it  =  q2  Add  i2  =  =  ((ql  =q2)  and  (it  =  i2)), 

Remove(NewQueueOf  Packet)  =  =  NewOueueOf  Packet. 
Remove(q  Add  i)  =  =  if  q  =  NewOueueOf  Packet 
then  q 

else  Remove(q)  Add  i, 

Append(q,  NewOueueOf  Packet)  =  =  q, 

Append(q,  ql  Add  it)  =  =  Append(q,  ql)  Add  it, 

que(i)  =  =  NewOueueOf  Packet  Add  i, 

Front(q  Add  i)  *  =  if  q  =  NewOueueOf  Packet 
then  i 

else  Front(q), 

Back(q  Add  i)  =  *  i, 

i  in  NewOueueOf  Packet  *  *  FALSE, 
i  in  (q  Add  it)  *  =  (i  in  q  or  (i  s  it)); 

rulelemma 

Append(  NewOueueOf  Packet,  q)  b  *  q; 

schemas  Nor  malForm(q)  =  =  caaes(Prop(  NewOueueOf  Packet), 
all  qq.  ii  (Prop(qq  Add  ii))). 


43 


REFERENCES 

1.  Berthomieu,  B.,  Proving  Progress  Properties  of  Communication  Protocols  in  Affirm,  USC/lnformation 
Sciences  Institute,  Program  Verification  Project,  Affirm  Memo  35,  September  1980. 

2.  Cohen,  D.,  and  Y.  Yemini,  "Protocols  for  dating  coordination,"  in  Proceedings  of  the  4th  Berkeley 
Conference  on  Distributed  Data  Management  and  Computer  Networks ,  pp.  179-188,  University  of 
California,  Lawrence  Berkeley  Laboratory,  Berkeley,  August  1979.  (Also  in  The  Oceanview  Tales , 
USC/lnformation  Sciences  Institute  RR-79-83.) 

3.  Floyd,  R.  WM  "Assigning  meanings  to  programs,"  in  I  T.  Schwartz  (ed.),  Proceedings  of  Symposia  in 
Applied  Mathematics,  pp.  19-32,  American  Mathematical  Society,  1967. 

4.  Gerhart  S.  L.,  et  al.,  "An  overview  of  Affirm:  A  specification  and  verification  system,"  in  Proceedings 
1FIP80 ,  pp.  343-348,  Australia,  October  1980. 

5.  Goguen,  J.  A.,  J.  W.  Thatcher,  and  E.  G.  Wagner,  "An  initial  algebra  approach  to  the  specification, 
correctness,  and  implementation  of  abstract  data  types,"  in  R.T.  Yeh  (ed.).  Current  Trends  in 
Programming  MethodoIog}\  pp.  80-149,  Prentice-Hall,  1978. 

6.  Guttag,  J.  V.,  The  Specification  and  Application  to  Programming  of  Abstract  Data  Types ,  Ph.D.  thesis. 
University  of  Toronto,  Department  of  Computer  Science,  October  1975. 

7.  Guttag,  J.  V.,  E.  Horowitz,  and  D.  R.  Musser,  "Abstract  data  types  and  software  validation," 
Communications  of  the  ACM  21,  December  1978, 1048-1064.  (Also  USC/lnformation  Sciences  Institute 
RR-76-48,  August  1976.) 

8.  Guttag,  J.  V.,  and  J.  J.  Horning,  "The  algebraic  specification  of  abstract  data  types,"  Acta  Informatica  10, 
1978,  27-52. 

9.  Liskov,  B.  H.,  and  S.  N.  Zilles,  "Specification  techniques  for  data  abstractions,"  IEEE  Transactions  on 
Software  Engineering  SE-1  (1),  March  1975,  7-19. 

10.  Musser,  D.  R„  "Abstract  data  type  specification  in  the  Affirm  system,"  IEEE  Transactions  on  Software 
Engineering  SE-6  (1),  January  1980,  24-32. 

11.  Owicki.  S.  S.,  and  D.  Gries,  "Verifying  properties  of  parallel  programs:  An  axiomatic  approach," 
Communications  of  the  ACM  19  (5).  May  1976. 

12.  Postel,  J.  B ,  ed.,  DoD  Standard  Transmission  Control  Protocol.  Prepared  by  USC/lnformation  Sciences 
Insutute  for  DARPA-IPTO,  January  1980.  (Also  in  ACM  SIGCOMM  Quarterly  Review.  October  1980.) 

13.  Schwabe.  D.,  Formal  Techniques  for  Specification  and  Verification  of  Protocols,  Ph.D.  thesis.  University 
of  California,  Los  Angeles,  Computer  Science  Department,  March  1981.  (Also  UCLA  Technical  Report 
ENG  8209.) 

14.  Spiu.en,  J.,  and  B.  Wegbreiu  "The  verification  and  synthesis  of  data  structures,"  Acta  Informatica  4, 

1975,  127-144. 

15.  Sunshine,  C.  A.,  and  Y.  K.  Dalai,  "Connection  management  in  transport  protocols,"  Computer 
Networks  2  (6),  December  1978. 


44 


16.  Sunshine,  C.  A.,  Formal  Modeling  of  Communication  Protocols ;  U  SC/In  formation  Sciences  Institute, 
RR-81-89,  March  1981. 

17.  Thompson,  D.  H.,  S.  L.  Gerhart,  R.  W.  Erickson,  S.  Lee,  and  R.  L.  Bates,  eds.,  The  Affirm  Reference 
Library \  USC/ In  formation  Sciences  Institute,  1981.  (Five  volumes:  Reference  Manual,  User’s  Guide, 
Type  Library,  Annotated  Transcripts,  and  Collected  Papers;  450  pages.) 

18.  Thompson,  D.  H.,  C.  A.  Sunshine,  R.  W.  Erickson,  S.  L.  Gerhart,  and  D.  Schwabe,  Specification  and 
Verification  of  Communication  Protocols  in  Affirm  Using  State  Transition  Models ,  USC/lnformation 
Sciences  Institute,  1SI/RR-81-88,  March  1981.  (Also  submitted  for  publication.) 

19.  Tomlinson,  R.  S.,  "Selecting  sequence  numbers,"  in  Proceedings  of  the  ACM  SIGCOMM/SIGOPS 
Interprocess  Communications  Workshop ,  pp.  11-23,  ACM,  Santa  Monica,  California,  March  1975.  (Also 
IFIP  TC6.1  (IN WG)  Protocol  Note  No.  2,  August  1974.) 


